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Abstract 

Anrang its otb^ jeJiajacteTistkai a programming language should be conducive to 
writing modular programs, be able to express pwratititinittjaa^ aon-determlnat» beiiavior, 
and it should have a cleanly fonnalizable semantics. Data flow programming languages 
have' all these clteracteristics and are 'especially* amenable to mathematizatipn of their 
semantics in the denotational style of Scott and Strachey. Many real world programming 
problems, such as operating systems and date base inquiry systems, require a program* 
ming language capable of non-determinacy because of the non-determinate behavior of 
their physical environment. To date, there has been no satisfactory denotational 
semantics of programming languages with non-determinacy. This dissertation presents a 
straightforward denotational treatment of non-determinate data flow programs as 
functions from sets of tagged sequences to sett of tagged sequences. A simple complete 
partial order on such sets exists, in which the data flow primitives are continuous 
functions, so that any date flow program computes a well defined function. Abo 
presented are suggestions for extensions of this semantics, discussions of "fair" non- 
determinacy and other questions, and the relation of this approach to other approaches. 
In particular, it is unnecessary to use the "power domain" construction in order to 
handle simple non-determinacy in date flow languages. 
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Introduction 



Need for Formal Semantics 

The success of syntax theory in making precise the syntax of programs led investiga- 
tors to attempt to describe the semantic behavior of programs with equal precision. In 
particular, in order to prove theorems about the behavior of programs, it is necessary to 
have a mathematically precise set of axioms which define how programs behave. These 
axioms define the way in which the elementary semantic units behave (where elementa- 
ry units are the basic data, operators, statements, etc.) and how the behavior of com- 
pound semantic constructs (such as expressions, statement lists, etc.) behave in terms of 
their components, elementary or compound. 

The major truth one wishes to be able to prove about a program is that it does what 
it is supposed to do. There are two ways of expressing this: that it meets some specifica- 
tion, or that it does what another program does (which is known correct). Proving that 
one program does what another does is usually called proving program equivalence, and 
is not decidable in general. Proving that a program meets some specification requires 
having a formal statement of that specification (which also must be known correct, a 
point sometimes overlooked) and then proving that the behavior of the program is 
consistent with the specification. Such specifications (usually expressed in predicate 
calculus, the "assembly language" of the specification world) are often more compact 
than an equivalent program known to work, but they are not necessarily more perspicu- 
ous, since they may contain much that is "non-constructive" which programs by defini- 
tion cannot. That a program meets its (formal) specifications is also undecidable in 
general. 

There are other things that one might want to prove about a program. The most 
common is that the program terminates for all of its "legal" input, that is; one wants to 
prove that its domain of definition is what one thought. A second property worthy of 
proof is that the program consumes (no more than) a certain amount of time or space; 
the efficiency of a program is almost as important as its correctness. Obviously, a 



mathematically precise semantics for programs is needed in order to construct mathe- 
matical proofs such as these. 

There are three main approaches to precise semantics: the operational, the axiomat- 
ic, and the denotational or functional semantics. The operational approach, based on 
the notion of an abstract interpreter, is the most intuitive of the three, but it is rather far 
from the mainstream of mathematics, so that it is difficult to invoke many useful 
theorems or other tools. The axiomatic approach of Floyd [Flo-67] and Hoare [Hoa-69], 
which views a program as relating (in the mathematical sense) the "before" state of the 
abstract machine to its "after" state, has the disadvantages that it needs something that 
has a state, and that relations are less convenient than functions. The functional 
approach of Scott and Strachey [S&S-71] treats the semantic behavior of a program as a 
function from inputs to outputs, a well known kind of mathematical object. 

The tractability of the formal semantics of a programming language depends more 
on the elegance of that language than on the class of semantic model chosen, however. 
We will present a programming language whose semantics we trust is quite tractable, 
considering its scope. 

Need for Modularity 

If a program is large, it is important that it be decomposable into parts, called 
modules, each of which performs a well defined function (at least in the informal, if not 
the formal, sense). Furthermore, it is important that the interactions of the modules 
with each other be held down to a reasonable amount. That is, the functions performed 
should be as independent as possible besides being well defined. The purpose of 
modularization, of course, is to keep the program understandable, since it is the rare 
person who can comprehend a large system with many interdependencies. In fact, since 
the number of interdependencies can grow exponentially in the number of components 
(consider all K way interactions, for K<>N), one might consider the point of modulari- 
zation to reduce such exponential growth to a more tractable polynomial or even linear 
growth. If the program is quite large, a hierarchy of modules is more appropriate. Then 
each module at the top level is composed of modules, each of which is in turn composed 
of modules etc., until the modules are simple enough to be understood without further 
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decomposition [Sim-69]. This hierarchical decomposition need not be a tree, a submo- 
dules may be shared (e.g. both the carburetor and the automobile as a whole contain 
screws). 

A program which is well partitioned into modules also is more likely to be proved 
correct (assuming that specifications for it can be formulated) . The approach to proving 
such a program, as one might expect, is to prove that each module properly implements 
its well defined function, and that the modules are interconnected so as to meet the 
overall specification. If the program is a hierarchy of modules, this process is repeated 
for each level of the hierarchy. 

Modules are often realized as subroutines, or more likely, in large programs, as 
collections of subroutines sharing data. An extreme case of modularization may be 
found in data abstractions as exemplified by the CLU language. Roughly speaking, data 
abstractions are collections of subroutines which provide and enforce access functions 
for an extended (e.g. user defined) data type. The way in which data abstractions differ 
from the ordinary way of providing access functions is that the only way to access 
objects of that type is through the subroutines of the data abstraction. Thus data 
abstractions assure that the program is modularized as claimed and that no one is 
"cheating" by violating the module boundaries. 

This thesis presents a language which is uniquely disposed towards modularization, 
both in its syntax and its semantics. Since its semantics is based on the mathematical 
notion of function, it is possible for modules to perform one function in the formal sense. 
Thus this language and its semantics may provide a basis for proving properties of large 
programs expressed in it. 

Need for Parallelism 

There are several situations in which parallelism is desirable or necessary in a 
programming language. The first situation is when the problem to be solved is inherent- 
ly parallel. The classic example of this is a multi-user computer system. Each user sits 
at a terminal making independent requests to the computer. Since the users are inde- 
pendent, and since persons live their lives in parallel with one another, it follows that the 
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computer system must be able to serve these requests in parallel Cue. simultaneously 
with respect to an appropriate time granularity). In order to serve the requests Iri 
parallel, some part of the computer's program must be capable of parallel operation. In 
the case of a regular time sharing system such as vm/370 (the purest case), it is only the 
supervisory program which operates in parallel, each user appears to have a virtual 370 
on which she runs her programs sequentially. In fact, operating systems in general need 
parallelism [Ko»-73b]. 

The next case in which parallelism is desirable is when there is some hardware 
(especially CPU) with actual parallel processing capacity and the user wishes his 
program to take advantage of it in order to run faster in total elapsed time. A typical 
example of this is performing weather (hydrodynamic) calculations on a highly parallel 
computer such as ILLIAC IV. Here, the extra speed gained by performing calculations 
simultaneously on many grid points makes the difference between useful answers and 
not (nobody wants to predict yesterday's weather). 

These two cases of parallelism in program operation are rather different. In the 
first case, the simultaneous operations tend to be doing different tasks, while in the 
second case, they all are performing nearly the same computation, but on different data. 
Different progratmnaig language appr^ to cope with these 

different cases. To handle the first case, muW-tasfeing facilities often have been added 
to an otherwise conventional programming language. Por example, PL/i has the TASK 
option on the CALL statement, which causes the invoked procedure to be tun as an 
independent, parallel task or process. In ALGOL style languages* the parallel statement 
approach is favored; this is a compound statement whose component statements are to 
be executed in parallel with one another, rather than serially in the order they are 
written. In both these language classes, some synchronization operations are provided 
also because the parallel paths are never tamlly independent of one another. 

The second kind of parallelism is often handled without any specialized features in 
the language, but is rather accommodated entirely by the compiler. For example, APL is 
a sequential programming language with array data and an extensive collection of array 
operators, but with no emphasis on parallelism. However, it is easy to imagine an 
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interpreter or compiler for APL programs which compiles in a fashion to take full 
advantage of the array processing parallelism of the ILLIAC IV. 

There is a third kind of parallelism that is desirable in programming that is not truly 
supported by any common programming language. That is parallelism for the sake of 
omitting unnecessary detail. The course of programming language development has 
been to create languages of ever "higher level", where by higher level is meant a 
language in which less implementation detail need be specified. For example, FORTRAN 
introduced the notion of arithmetic expression, LISP the notion of automatic storage 
management, and most recently, CLU and others have introduced the notion of abstract 
data type, an advanced form of data representation independence. All of these lan- 
guages, however, still demand that the programmer specify that operations take place in 
some serial order, even though problem only demands that the operations take place in 
some partial order. The only case in which the exact order need not be specified is 
when the language has operations which operate on structured data as a whole; then the 
order of operation on the components need not be specified. But if one is defining an 
operation on structured data, the irrelevant total ordering of component operations may 
again creep in. For example, in defining a complex add operation, it doesn't matter 
whether the real parts are added first or the imaginary parts are added first. 

What is needed, then, is a programming language which supports all three kinds of 
parallelism, parallelism demanded by the nature of the problem, parallelism demanded 
by the need for execution speed, and parallelism needed to suppress unnecessary 
implementation detail. 

Need for Non-determinate Behavior 

Although it is generally considered desirable for programs to be determinate (to 
always give the same output when presented with the same input) there are certain cases 
in which determinate behavior would be crippling. Consider the classic example of an 
airline reservation system: it consists of a central computer(s) and data-base connected 
to a number of agents' terminals. Each agent works independently, requesting informa- 
tion and booking reservations. Thus the behavior of the system must include some 
dependency on the arrival time of the transactions — the last seat on a flight must be 
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given to the person who requests it first (where "first" means at least e earlier). But 
such timing dependency is contrary to the notion of determinate behavior. If the system 
were to operate completely determinately, there would be no way for the system to 
transact with the agents at their convenience, but only according to a rigorous schedule. 
If one agent were out to lunch unexpectedly, for example, all the other agents would be 
delayed while the system waited for that agent's response. The way out of this difficul- 
ty, of course, is to include the arrival time as part of the input data, then the time 
dependency reduces to a data dependency, which is determinate. However, the part of 
the system which performs this operation is itself nondeterminate, but it is an isolated 
singularity. 

The part of the system mentioned above which merges multiple sources of inputs 
into one output and perhaps tacks on the arrival time of each input is often called an 
arbiter. (The very act of merging several input streams into one output stream attaches 
an ordering to the arrivals of the separate inputs, so often an explicit arrival time may be 
dispensed with. ) Given such an arbiter, which merges several streams of inputs into one 
output stream, a question which is of much concern is the question of fairness, that is, 
whether the input streams get equal treatment by the arbiter. In particular, might inputs 
one some ports get accepted preferentially to inputs one some other ports, or worse yet, 
is it possible that the inputs presented at some input port be held up indefinitely while 
inputs from other ports are accepted freely. Both of these behaviors are conceivable for 
arbiters (since, by their very name, their merging is arbitrary) but, although the priority 
treatment of certain inputs might be desirable, the indefinite delay of some inputs when 
there are no other inputs is almost certainly undesirable. 

We may conclude from this discussion that a programming language must allow 
nondeterminacy but that it is rarely necessary to use it, and when it is, the arbiter seems 
to be an appropriate construct. The question then arises as to whether the nondetermi- 
nate arbiter operation which is provided is fair or not (and which meaning of fair 
applies). Therefore, any semantics of such a programming language surely must be able 
to cope with nondeterminacy and with the question of fairness. 
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Overview of Dissertation 

In an attempt to meet the four needs outlined above, this dissertation sets forth and 
analyzes an unconventional kind of programming language, called a data flow program- 
ming language [Den-73, Kos-73]. This semantics of this language is defined in terms of 
mathematical functions, yet the functions transform the data of interest rather than the 
state of the machine, so modularity is achieved easily by means of function composition. 
The two dimensional syntax of the language provides parallelism in a natural manner, 
both in terms of the elimination of detail and the specification on independent tasks. 
The ability of the language to operate on structured data means that parallelism of such 
operations is also possible. Finally, the language allows non-determinate programs, and 
has a relatively straightforward semantics for non-determinacy, but the language 
construct for non-determinism allows the programmer to isolate the non-determinate 
behavior in small sections of the program, thus allowing the analysis of most of the 
program in the simpler determinate semantics. 

The major part of the dissertation deals with the denotational semantics of non- 
determinate data flow programs. The necessary domain for the functions is defined and 
its properties proved; then the primitive operators in the language are functionally 
defined and they are proved to have the necessary mathematical properties. In particu- 
lar, chapter 2 discusses and informally defines data flow programming languages, 
chapter 3 gives background on mathematical semantics, chapters 4 through 6 contain the 
formal definitions and proofs, and chapter 7 concludes with discussion of several points. 
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-2- 
Data Flow Programming Languages 

Background 

In recent years a new class of programming languages, called data flow languages, 
has evolved [Den-73, Kos-73], Unlike most programs, the execution of data flow 
programs is governed solely by the availability of data, both input and computed, rather 
than by the movement of one or more abstract locuses of control. A data flow program 
may be represented by a ftowchaffctifce network of operators connected by data paths. 
Each operator executes when the data it needs is present on its input paths yielding 
transformed data on appropriate output paths. Operators are strictly local in effect, that 
is they can influence one another only by means of data sent via the paths. New 
operators may be defined as networks of other o per ators , analogous to subroutines, and 
recursive definitions are permitted. 

One of the virtues of data flow programming is that it allows parallelism to be 
expressed in a natural fashion. Furthermore, the parallelism can be guaranteed determi- 
nate, if desired. The expression of parailelitm is one of the eariy reasons researchers 
were attracted to data flow. However, data flow is now known to have other advantages 
as well. The two most important are tecalitjr of effect and applicative behavior. 
Applicative behavior means that data flow operators 4m be characterized as mathemati- 
cal functions. Locality of effect means that the mathematical equations for a data flow 
program can be derived simply by conjoining the equations for the various parts of the 
program in an "additive" manner. In spite of its applicative behavior, an operator may 
be a function from input sequences to output sequences and thus exhibit an (internal) 
state with regard to single inputs and outputs. Therefore, data flow languages can be 
analyzed mathematically almost as easily as ■'toy" applicative languages (e.g. pure LISP) 
but are more powerful in that they provide parallelism and "state". 

Informal Semantics of DFPL, a Data Flow Programming Language 

The data flow language which will be considered in depth in this paper is a develop- 
ment of the author [Kos-73], and is called DFPL for brevity. 
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A DFPL program is a directed graph whose nodes are operators and whose arcs are 
data paths. Operators in DFPL functionally transform their inputs to their outputs 
without ever affecting the state of the rest of the program. Since there is no control 
flow, there is no GOTO; in spite of this, loops may be programmed as well as recursion. 
Most significant though, is the fact that unlike ordinary applicative languages, programs 
may exhibit memory behavior: that is, the current output may depend on past as well as 
current inputs. The effects of memory are local like those of other operators and it does 
not permeate the semantics of programs. 

Data in DFPL are pure values, either simple like numbers or compound like arrays 
and records. There are no addresses as primitive data in DFPL, although compound 
operators may be defined to interpret data values in a manner reminiscent of addresses. 
An operator "fires" when its required inputs are available on its incoming paths. After 
an unspecified interval, its sends its outputs on its outgoing paths. It is not necessary 
that all inputs be present before an operator fires; it depends on the particular operator. 
Similarly, not all outputs may be produced by a given firing. A synchronous operator is 
one which fires only when all its inputs are present and it produces all its outputs at 
once. The outputs may depend on past inputs as well as current inputs. If the outputs 
of a synchronous operator depends only on current inputs, the operator is said to be 
simple. Synchronous operators are analogous to subroutines (with "own" or "static" 
variables if the operator is not simple). Some operators produce a time sequence of 
output values from one input value or conversely; they are analogous to coroutines. The 
operators in a DFPL program thus operate in parallel with one another subject only to 
the availability of data on the paths. 

An operator may either be primitive or defined. An operator is defined as a 
network of other operators connected by data paths such that some paths are connected 
at one end only. These paths are the parameters of the defined operator. An instance 
of a defined operator operates as if its node were replaced by a copy of the network 
which defines it and the parameter paths spliced to the paths which were connected to 
that node. This "copy rule" allows recursive operators to be defined. 

Sufficient synchronization signals are passed with the data on the paths so that 
operators do not fire prematurely, and so that operation of the program as a whole is 
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independent of the timings of the component operators (at least in basic DFPL, full DFPL 
allows timing dependent programs in order to cope with the real world). 

Classes of Operators 

There are three classes of operators in DFPL: simple operators, including the usual 
arithmetic, logical and aggregate operators stream operators, including the primitive 
Switch operators (for conditionals and other data routing) and primitive Hold operator (for 
memory and iteration); and non-determinate operators, including the primitive Arbiter 
(for coping with the non-determinate physical world). Simple operators all have the 
property that they demand all their inputs to fire, whereupon they produce all their 
outputs. Furthermore, each firing is independent of any past history, that is, the 
operator is a function from current input to current output. 

Stream operators sometimes do not accept/produce aH their inputs/outputs, or their 
current output may depend on past inputs. Thus we can not describe their functional 
behavior as simply as before (not producing an output is not the same as producing a 
null output). But we can describe their behavior it we view them as functions from 
streams (sequences over time) of inputs to streams of ou^iuts. Not all computable 
functions from streams to streams describe stream operators however; the function must 
be causal, that is* the operator may never retract some output upon receiving further 
input. 

Non-determinate operators produce any one of a set of output values (according to 
whim, or in a real implementation, timing considerations) when presented with specified 
input values. The primitive Arbiter operator* upon which other non-determinate 
operators may be based, takes as input two or more streams and produces as output a 
stream which is the result of merging the input streams M some arbitrary way. Non- 
determinate operators may be viewed as relations from streams to streams, or more 
profitably, as we shall soon see, as functions from sets of streams to sets of streams. 

Synchronous operators allows us to avoid the tedium of using a separate index for 
the stream of values on each data path. All paths in a subnetwork of synchronous 
operators may share the same stream index since that subnetwork behaves as a single 
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synchronous operator. Note that all simple operators are synchronous and stream 
operators may or may not be synchronous. Also, any defined operator constructed 
entirely out of synchronous operators is itself synchronous. 

Primitive Operators 

There are five primitive operators in basic DFPL (shown in Figure 2.1). Of these, 
two are simple in their behavior: the Fork and the primitive computational function or 
Pcf. The Fork is a multi-output identity function, that is, a copy of its input is sent to 
each of its outputs. The Pcf is really a whole set of operators including the usual 
arithmetic, logical and aggregate operators (e.g. Construct and Select). The Modify 
operator is an example of a Pcf which typifies DFPL in that it generates new data rather 
than updating existing data. Modify takes three inputs, an array A, an index J and a 
value V, and produces one output, a new array Anew, which is a copy of A except that 
Anew l - V. Note that the Fork and all Pcf operators are synchronous. Since Forks 
have such simple functional properties we do not treat them as explicit operators on 
proofs, but rather just label all their paths the same. 

The most complicated of the primitive operators are the Switch operators, also 
shown in Figure 2. 1 . These two operators have the property that each firing is inde- 
pendent of previous firings, but not all inputs/outputs are demanded/produced upon 
each firing. The outbound Switch or Oswitch, for example, demands C and U as inputs 
for each firing, but only one of X, Y and Z receives output in any firing. Which one 
receives the output, which is just the input value U, is determined by the value of the 
input C. The inbound Switch or Iswitch operates conversely, only one of the inputs X, 
Y, Z is accepted upon firing (C is always demanded), and its value is always sent out on 
U. 

Informally speaking, an Iswitch merges two or more data streams into one data 
stream of the same length as the control stream, selecting which input data stream to use 
next according to the current value on the control stream. Conversely, an Oswitch splits 
a data stream into two or more data streams dependent on the values of the control 
stream. Figure 2.2 exemplifies the behavior of both Iswitch and Oswitch according to 
which paths are input and which are output. In both cases, the ordering(s) of the output 



■16- 



stream(s) is consistent with the ordering(s) of the input streamCs). Although the vaiue 
of an output from a Switch is dependent only on th«CB«|8f« J^wt values for this firing, 
the position of that output value in its stream is dependent on previous firings, hence 
neither Suritch is a simple operator. 

Since these operators sometimes do not demand/produce inputs/outputs, we can 
not describe their functional behavior as simply as before (not producing an output is not 
the same as producing a null output). But we can describe their behavior if we view 
them as functions from streams of inputs to streams of outputs. 

The most interesting primitive operator m%H)ic®WK > is that which behaves like a 
kind of memory cell. It is just a holding station, that is, the output is what the input was 
on the previous firing and the initial output is its constant parameter. That is, Out 1 * l - 
In J and Out 1 - Q. The Hold operator is interesting because it is sufficient to construct 
any kind of memory desired, yet itself is purely functional talbeit from input streams to 
output streams). It can also be used to construct iteration. 

All of the above primitive operators are causal in the sense that an output cannot be 
affected by future inputs; that is, once an output is produced, it cannot be changed. 

Some Compound Operators 

SwiteA operators are most often used ^ia*tehed pa^ witti tbe coawcl mput of 
each connected, via a Fork, to the same source of a control stream. When -connected in 
tins way, the DFPL version of a conditional expression results, -as. shown, in Figure 2.3. 
The equivalent expression is If P(X)ThmFtX}Qth0rwia*G(X). 

Figure 2.4 shows a definition of a repeating constant operator. Tins operator takes 
no inputs but produces an (infinite) stream of output values, aft the same (3). 

A fancier memory cell is shown in Figure 2.5. When a Q value is presented on the 
control path C, the current contents is read out onto path Y. When a 1 value is present- 
ed on C, and a data value presented on input path X, the cell is updated to contain that 
new data value. The cell has an initial contents of Q. 
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The Primitive Non-determinate Operator 

To allow the construction of programs with indeterminate behavior, we define an 
operator which merges its input streams in an arbitrary manner. This operator, called 
the Arbiter, is shown in Figure 2.6. Speaking informally, the Arbiter operator merges 
two or more input streams into an output stream whose order of items is consistent with 
the separate orders of items in the input streams. This merging is done randomly (or 
arbitrarily) analogous to shuffling together two decks of cards. The Arbiter also 
(optionally) generates a stream of control values which tells exactly how the merge was 
performed. This control stream is of a form such that if it is fed to an Otwitch, the 
merged stream can be unscrambled into its component input streams. The optional form 
of Arbiter can be programmed from the more primitive form, which does not generate 
the control stream output, together with a Fork and an Iswitch. 

Since the Arbiter produces an output stream chosen randomly from a set of possible 
output streams, we might characterize the Arbiter as a relation from input streams to 
output streams. However, since the the fixed-point theory of functions is better under- 
stood, we will treat the Arbiter as a function from (sets of) input streams to sets of 
output streams. We consider sets of input streams even though intuitively the Arbiter 
works on individual input streams because we wish the domains and codomains to be 
compatible. 

In extending the semantics of DFPL to accommodate the Arbiter, the semantics of 

the determinate operators must be upgraded also. This upgrading is the obvious one of 

saying that the determinate operators map sets of input streams into sets of output 

streams pointwise, that is, each stream in the input set gets mapped to a single stream in 

the output set by applying the old stream-to-stream function of the operator. Multiple 

input operators are more complicated. If the input sets originate at the same Arbiter, 

then the operator is applied to corresponding streams from the input sets in a manner 

similar to an inner product of vectors. If the sets originate at different Arbiter,, then 

the operator is applied to the Cartesian product of the sets. If the sets have mixed 

origins, that is have some Arbiter in common which affected their computation, as well 

as independent Arbiters, then a mixture of inner and outer (Cartesian) products must be 

taken. Thus, the determinate operators produce output sets whose cardinalities are no 

bigger than the product of the cardinalities of the input sets. The indeterminate Arbiter, 
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unfortunately, tends to cause cardinalities to get out of hand, since the output set 
cardinalities depend on the input set elements (i.e. the number of ways they can be 
merged) as well as the input sets cardinalities. 

Examples 

The DFPL program shown in Figure 2.7 is an example of a procedure definition. 
The procedure performs the multiplication of two complex numbers with a high degree 
of parallelism. Figure 2.8 shows a DFPL procedure for computing the mythic recursive 
factorial function. Figure 2.9 shows a DFPL procedure which implements a random 
access memory of 1 000 cells, each initialized to 0. 

The program illustrated in Figure 2.10 takes advantage of the fact that the optional 
control output of an Arbiter may be used to control an Oawiteh to unscramble the 
merging performed by that Arbiter, If the operator F is simple, that is, it is a function 
from its current input to its current output (thus independent of previous inputs), then 
the defined operator Triple- / behaves exactly as three copies of F applied separately to 
U, V, and W producing X, Y, and Z respectively (see Figure 2.11). However, the 
operator F is shared among the three input and output paths and therefore saves 
resources as compared to three copies of F. Of course, this is at the cost of running at 
least three times slower. Most important, even though ta# internals of Triple-/ are 
indeterminate, the behavior of Triple-/ as a whole is functional and ttms determinate. 
Therefore, it is possible to construct determinate programs using indeterminate compo- 
nents, and furthermore, proving one has done so is not necessarily difficult. 

Other Data Flow Languages 

One of the earliest pure data flow models of programming was developed by 
Rodriguez [Rod-67] This provided most of the capabilities of DFPL except for operator 
definition, and, thus, recursion. Programs m this language Were guaranteed determinate 
in operation. 

Luconi developed a model of parallel computation [Luc-68] which was more general 
in some ways than Rodriguez's. However, because a relatively conventional sort of 
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memory cell was necessary to hold data for the operators (approximately one such cell 
per operator) , determinate behavior could not be guaranteed, except by following strict 
conventions in programming. 

Adams developed a pure data flow programming language [Ada-68] similar to 
Rodriguez's and DFPL except that data paths were FIFO queues of unbounded length. 
This makes direct hardware implementation impossible; it is possible for DFPL without 
recursion if data types are of bounded size (e.g. FORTRAN numbers and arrays). Ft is 
presumably possible to directly implement Rodriguez's language in hardware also. 

At the same time as DFPL was developed, Dennis independently developed a Data 
Flow Procedure Language [Den-73] which is almost identical in terms of its primitive 
concepts. In its original form, it lacked an indeterminate primitive operator (present in 
DFPL) so that indeterminate programs could not be constructed. Further restrictions on 
the construction of programs in Dennis' language were imposed to ease the mathemati- 
zation of the semantics. These restrictions also simplify direct execution by a data flow 
processor (hardware). Thus, certain semantic behaviors, permissible in our DFPL, were 
not allowed in Dennis' original language. 

Of the four languages mentioned here (other than DFPL), only Dennis' is having a 
denotational semantics developed for it. Stoy [Sto-74] and Ciccarelli [Cic-76] have 
mathematized the semantics of this language. 

A related class of programming languages is those conventional languages which 
include interprocess communication mechanisms. Examples of these are suggested by 
Hoare's "communicating sequential processes" [Hoa-78] and Kahn and MacQueen's 
"coroutines and networks of parallel processes" [K&M-78]. Yet another kind of lan- 
guage related to data flow languages is LUCID of Ashcroft and Wadge [A&W-77]. This is 
a language which is applicative yet works on streams of data. 
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-3- 
Background on Mathematical Semantics 



Kinds of Mathematical Semantics 

The two approaches to mathematical semantics are, as stated earlier, the axiomatic 
and the denotational or functional. In the axiomatic approach, each primitive operation 
in the programming language has associated with it one or more axioms which formally 
specify the effect the operation has on the state of the abstract machine when that 
operation is executed. That is, the axioms describe the mathematical relationship 
between the "before" state and the "after" state. This relationship may or may not be 
functional. A sequence of operations have an effect which is the composition of the 
individual relations for the component operations. A loop in the program requires an 
inductive proof based on the relationship implied by the loop body and loop predicate. 
The inductive assumption (often called the loop invariant) may either be given or 
deduced from the initial and final conditions. A recursive program requires an inductive 
argument also. 

Programs which modify data structures as side effects are hard to deal with in any 
semantics. The usual axioms for assignment are not directly applicable when the 
assignment is to some computed variable. This situation arises with assignment to array 
components, with assignments indirectly via pointers, and with "aliasing" of any data 
objects via procedure parameters. This remains one of the open problems in axiomatic 
semantics [CfcO-78]. 

As is well known, programs which loop or recur sometimes do not terminate. 
Unfortunately, the inductive proof of a loop's behavior mentioned above often does not 
prove termination, but only the behavior of the loop if it terminates. The termination 
property (often) must be proved as a separate result. A new axiomatic semantics called 
dynamic logic, which is based on modal logic [H&P-78], allows one to treat termination 
simultaneously with "partial correctness", (as the behavior assuming termination is 
frequently called). An extension to dynamic logic allows one to treat non-determinacy 
as well [H&P-78]. 
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Thus, given a program together with a set of assertions about its behavior, one might 
determine by theorem proving (manual or automatic) whether the program satisfies its 
assertions. Alternatively, one might derive an assertion which describes the program's 
behavior. 

In the denotational approach, each p*hai§it*%|6i^ described 

by associating with it a v §emintifc function" which it computes. Thus, s sequence of 
operations compute* tte function which k the mwipoMriO a of the component operations' 
function*. If the operations are pemtm&-&p*tm^imtom-wm& hsop, ti» compos- 
ite function is not so easily (letermined (in the ajaomatk aperoach, an; inductive proof is 
needed) . Setting up the functional equatioa co**etpondiag to the loop, one gets: 

F(X) -If Te*t(X) Then F(Body(X)) Otherwise X 

where Teat is the predicate of the WHILE, Body is the function which describes the body 
of the loop, and F is the function which describes the loop as a whole. This is a recur- 
sive definition, but it is hard to solve because the unknown, F, is a function. 

This approach can be used on applicative languages with relative ease since such 
languages are based on the ideas of functions and their composition. Unfortunately, 
applicative languages are seldom used for progra i LISP has nonappiicative 

operators such as GO, SETQ and RPLACD. the effect of such operators is to make the 
functional characterization of the program depart Iderably from the syntactic 

structure of the program. This occurs for two reasons. ?*&«, since some operators such 
as assignment (e.g. SETQ or worse, RPLACD) change the stale of the whole abstract 
machine, the function corresponding to such an onexator. must transform states into 
states. Then, in order to be compoaable* all operators., must nsform states, whereas 
the program is written as if most operators transform variables.. Second, control flow 
operators (of which LISP'S GO is a mild example) can cause both the. conditional and the 
loop structure of the program to become arbitrarily complicated. Structured Program- 
ming, with its insistence on a limited, disciplined set of control operators (e.g> IF-THEN- 
ELSE and DO- WHILE) prevents the second problem from occurring, that is, one recursive 
equation corresponds to one loop. The first problem remains however, since most 
. existing languages have state transforming assignment operators. 
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Mathematical Concepts 

A partially ordered set, or poset, is a set of objects together with a relation which is 
reflexive, transitive and antisymmetric. That is, VZ: X < X, VX,Y,Z:X< YAYZZ+X 
$ Z, and VX t Y:X<Y A YZX+X-Y. If , in addition, the relation holds in one direction 
or the other for every pair of elements in the set, the set is said to be totally ordered. 
The integers are totally ordered under the usual ordering, while the set of all subsets of a 
given set are partially ordered under the inclusion relation. A chain is a totally ordered 
(subset of a) poset. A set is said to be pre-ordered or quasi-ordered under a relation if 
the relation is reflexive and transitive (but not antisymmetric). The set of equivalence 
classes under the quasi-order form a partially ordered set, where X and Y are in the 
same equivalence class iff X £ Y A Y < X. 

A Cartesian product of posets is itself a poset under the pointwise partial order; that 
is, (Xa, Ya, Za) < iXb, Yb, Zb) iff Xa S Xb A Ya £ Yb A Za £ Zb. Since a function can be 
treated as an element of a large cartesian product (the product of identical copies of the 
codomain indexed by the domain), functions can be partially ordered also. The order is 
defined by: F < G iff VX: F(X) £ G(X) 

An upper bound of a subset S of a poset P is an element U € P such that V.X" e S:X 
< U. A supremum or least upper bound (often abbreviated l.u.b.) of a subset S is an 
element L€P such that VUeP:L$ U where the U"s are upper bounds of S. An 
infimum or greatest lower bound (often abbreviated g.Lb.) is the order duals of the 
above (which is obtained by replacing "£" by its converse relation ">"). Many posets 
of interest have a least element, called bottom ("i"), which forms a lower bound for all 
subsets. A lattice is a poset in which every two elements have both an infimum or meet 
and a supremum or join [M&B-67]. Note that M is the meet of X and Y if f M < X and 
M < Y and V5: B < X A B < Y ♦ B £ M , and the join is the order dual. Many lattices of 
interest have both a least and a greatest element. 

A function from a poset to a poset is said to be isotone iff V-X", Y'.X 5 Y + F (X) £ 
F(Y). (The term monotone is often used instead of isotone, but it is less precise since 
isotone corresponds to monotone increasing only [Ros-77]. ) 

A poset is said to be chain-complete iff every chain has a supremum (not necessari- 
ly in the chain itself ) . The integers are not chain complete, for example, but the real 
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numbers oil a closed interval are. Any chain complete poset necessarily has a bottom 
element — it is the supremum of tiie empty chain. A more interesting example of a 
cham complete poset is the set of alt finite and infinite sequences of elements of some 
set partially ordered by ..the prefix or initial sups^ewftithsxjm. (For example, AB < 
AtC$45CAandABSAJ0JIathisposet,thes^»rem« are the infinite sequences {length 
id). Theempiy sequence is thf|fe«telemento£th*eatire poset, but there is no greatest 
element. The poset may be pictured as a tree of infinite depth, where each (finite) node 
eorropondstoaXfrn^ **c leading away from the 

node is labeled with a different element from the underlying set of objects. We restrict 
our attention to chains which are countable, which dees net require the underlying set to 
be countable. For example, the set of subsets of the integers is uncountable, but the 
chains under the inclusion order each have a countable numher of elements. Although 
there are other varieties of completeness, such as directtd-set completeness in which any 
finite subset which has an upper bound has a si om now on we win mean 

"countable chain complete" whenever we say "complete". 

A function from one complete poset to another is said to be continuous iff it is 
isotone and preserves suprema; that is, iff the value of the function on the supremum of 
a chain in its domain is the supremum of the set of values which is the image of that 
chain. Note that since the function is isotone, it maps chains into chains. Also, note 
that the isotonicity of the function can be deduced from its continuity (suprema preser- 
vation), merely by considering finite chains, whose suprema are their greatest elements. 
It is an easily proved and useful fact that a function which maps a cartesian product of 
(complete) posets into a poset and is isotone (continuous) on each argument is also 
isotone (continuous) on the tuple. Similarly, the composition of two isotone 
(continuous) functions is in turn isotone (continuous). It is also straightforward to prove 
that the set of continuous functions from one complete poset to another itself forms a 
complete poset under the natural partial order, on functions #fmed above. 

Now we come to the point of introducing posets, completeness, isotonicity and 
continuity — the Tarski fixpoint theorem [Mar-76]. If F: P ~ P is an isotone function 
mapping a complete poset into itself, then F has a least fixpoint Z* That is 32*: ^(X) * X 
and VY:F(Y) - Y *X * la Furthermore, if F is continuous at well as isotone, we can 
"compute" its least fixpoint by a straightforward technique (actually the technique 
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involves taking a limit, so it is not computable in the ordinary sense) [Sto-77]. Consider 
the sequence i, Fix), FHfj>,1»{iy, !*(£}, etc, tl^ s*qtie*et fortM *«hain because i 
< FU) by definition of x and J^fx) £F'*Hi) because ^li-*is<Mi»ie. Therefore the 
sequence forms a chamwhieh^a^M » chain 

complete. If we form U.F'U) (where / € «), and call it X, we see that X equate 
UrWUW which by continuity equals F(\^F l {^),I) which equals **(X) a fixpoint of F. 
To show X is the least fixpoint, assume Y is a fixpoint. Then x i r and thus F(i)£ 
W)- r ? So by induction, F'U) S r andso XS Y. . 



Denotational Semantics 

In the standard treatments of denotational semantics one data element or function is 
. said to be less than another iff it is less well defined than the other, so that the partial 
order is an ordering by approximation or information content [S&S-71]. Fef Example, far 
the casejrf partial functions one. may be said to be grea|er than another if it extends the 
other, that is, it is defined on a larger domain and they agree in value on the smaller 
domain [Man-74], In the case of simple data, a "flat" partial order is often used, it 
consists of a set of data wlafoh are not -o^^.n^^^^hot^. and a bottom element 
which is less than any true datum. Such flat po^ts are not of interest in themselves, but 
are used to construct more interesting p*?aett as qu|toedb?low. 

Earner we indicated that it was d^fficulf to assign an tt overlflJ functional behavior to 
programs with loops because a r^ujpve equation resuh^ yhich has a function as the 
unknown. Such equation* can **• -. t ?h«|d i^^rtfin circumstances by means of the Y, or 
fixed pqint, operator. Thja^ifr^mjplic^ by {ha fact ^that in nunjf programmiiig 
languages, such as USP, BCPL and even PL/I, we wish to be able to treat functions as 
data objects. In order to mathematize this, we require that the domain of functions 
include functions from that dwririifttb tha*14b«afe s TMi Uieaas that the domain must be 
recursively defined: If we let?fbe«e domain eif «6i^fue«ti<mel data (euch as num- 
bers), then the domim 2* must b* IsoiadrpfBc* f& N m&^m the disjoint union of N 
and the set of (continuous) functionifrott & td ? <D:-SeWs oonmbation hw been to 
show that there exist lattices called reflexive domains wbWsatisfy this iidmorphBm and 
in which the Y operator can always apply to give Sfe unique niinimai fixed point solution 
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of the functional equations alluded to earlier. Furthermore, such domains adequately 
eharacterize programming languages. Thorough treatments of this approach to program- 
ming languag#«mantief may be found in [MAS*7&, Sto-77]. 

A slightly more recent approach to denotational semantics uses complete posets 
rather than complete lattices [ADi-77, Mar-76, fcos-77]. Such peseta accurately model 
the basic notion of approximation, and although the bottom element corresponds to 
"undefinedness", the "top" element of the lattice (and other joins necessary for the 
lattice to exist) do not seem to correspond to any computationally meaningful object. 
We do not use reflexive domains in this thesis, as we <to not, allow function valued data, 
but we do use posets rather than lattices, for the reasons stated. 

Notation 

Names of variables and functions are denoted by capitalized cursive italic words 
such as Var and Fun. This is more like programming notation than conventional 
mathematical notation, which tends to use single character symbols for all variables and 
functions, but it is more mnemonic and thus more readable when many names exist. 
Literal dau symbols are represented by austere italic letters such as A and by austere 
numbers such as 9 9 9. Literal data symbol* may be lagged by appending strings of 
miniature digits to the symbols, for example* Uo, 4o© , iiooi). 

The angle brackets "<** and ">** are used to enclose explicit sequences of data, for 
example U,B,<7>. Braces (i.e. "{"and U D denote sets in the usual way: [X, Y] 
denotes the set consisting of X and Y, while f X | liXii denotes the set of all X 
satisfying HX). 

Subscripts on names denote selection of a particular item from a set of similar items, 
for example Var 2 , Fu* v Superscripts on variables which are streams (sequences) 
denote selection of an element from that sequence, for example, 3/ denotes the /-th 
element of the stream S s , which in turn is the N-th stream of a set of related streams. 
Superscripts on data symbols mean repetition of that symbol, for example (A K ) denotes a 
sequence of K 4's. Superscripts on function names eijther denote repeated composition, 
if the superscripts are numeric constants or variables, or they denote a new function 
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related to that function denoted by the un-superscripted name, if the superscript is a 
greek letter. For example, F M (X) denotes the M fold application of F to X, whereas F* 
denotes the "extension" of F by some rule, and F u denotes the "completion" of F by 
some other rule. 

Finally, conventional mathematical notation is used for everything else: infix 
operators, prefix operators, quantifiers (with ":" separating the quantification from the 
body), function application and argument lists, and conditional expressions, including 
"If", "Then" and "Otherwise". 
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-4- 
Semantics of Determinate DFPL Programs 



Overview 

In this chapter we develop the fixed-point semantics of the determinate subset 
(really a sub-algebra) of DFPL. To do this we first show that the domain of Streams is 
suitable for fixed-point solutions of programs, then we show that the determinate 
operators are continuous on this domain. We therefore deduce that (recursion free) 
determinate DFPL programs have a well defined behavior no matter what inputs they 
receive. We conclude with an example of a simple fixed-point computation of a pro- 
gram containing a loop. 

A Complete Partial Order on Streams 

A Datum is an element of some set of data, for example, integers, characters, 
Booleans, arrays of floating point numbers, payroll records, directed graphs etc. The 
data sets available depend on the kind of DFPL programs being analyzed. We will not 
consider what types of data are available except that we shall assume that the integers 
are since they are needed to control the Switch operators. All data are assumed to be 
incomparable from the denotational point of view. That is, any ordering of data in a 
data set (e.g. the integers) is not of interest to us since it does not represent approxima- 
tion. 

A stream is a finite, empty or infinite sequence of data items, often denoted by 
enclosing their elements in angle brackets, for example, < ) for the empty stream, U , B , 
C , D) for a finite stream of length 4, and <A , B , . . . , Z , . . .) for an infinite stream. More 
precisely, a stream is a function from the positive integers or some initial segment 
thereof (including the empty set), to the set of Data. That is, S: Nseg - Data; where 
Nseg - { } (S the empty stream), or Nseg - tfl 1 £ / < N] (S a finite stream), or Nseg - {/ 
I / > 1} (S an infinite stream). Put another way, streams are functions whose domains 
are ordinals no bigger than « and whose codomains are some set Data. We denote the 
value of a stream at some integer / by S 1 , using superscripting for emphasis. A stream 
S, is said to be a "prefix" of a stream S 2 (denoted S, <gS 2 ) iff DomiSj s Dow(S 2 ) and S 2 
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restricted to DomiS,) (denoted S 2 \Dom(Sj) is equal to S,. That is, S.'-S/ for all /« 
XtowCS,). 

Theorem 4.1 : The prefix relation is a partial order on streams. 

Reflexrvity and transitivity follow from the reflewvity and transitivity of "c" and 
especially "*". The antisymmetry of "1" fellow from the a^^ of "s". 

Hence the set of streams form a discrete poset which weehtt &p*«t*wm». H 

Note that the bottom element of this poset is the empty stream (denoted i or ( », and 
the infinite streams are maximal elements of the poset 

Lemma 4.1: An indispensable property of Cpo-»tr**mt is the following: if S,, S 2 and 
S, are streams such that S,i5 3 and S 2 iS 3 , then etther S^S 2 or S 2 $S V This essen- 
tially says that the graph of the partial order is a tree, with the empty stream as the root 
and the infinite streams as the leaves. 

This follows easily from the fact that Dom(S { ) and Dom<S 2 ) are ordinals so Dom(S x ) 
fiDtHnCSp or DomiSj sltomXS,). We apply the definition of"*" to get S 3 1Item<S a >-S r 
and S 3 1Z>©to(S,) - S v Now, assuming DomiSj s Dom(S 2 ), we get S 2 1 Dom(S l )" S y \ 
DomU5 2 ) \DtmiSj which impUes SjJiWSp-S,, which means S^S 2 . Assuming 
DomCSj) c I?o»CS t ) gives us S 2 ±S X , which proves the property. H 

Lemma 4.2: If S, and S 2 are infinite, S x *S 2 iff 3, -S r 

Theorem 4.2: The poset Cpostreama is countable chain complete. 

To show that this poset is chain complete, we must prove that any chain of streams 
has a supremum in the poset. The chains are just sets of streams, {S,,S 2 ,...}, such that 
S < S 2 « . . . ; we need not worry that S t - 5, since a chain is a set. There are four cases 
to be considered: if the chain is empty, then its supremum is x. If the chain is finite, 
then its supremum is just its maximal element. If the chain is infinite and contains an 
infinite stream S, then S is the supremum of the chain, since S* S and for all finite S r S, 
< S< and for no finite S^ is S H 1 8, for all finite 3 P and no other infinite stream can be in 
the chain. If the chain is infinite but contains only finite streams, then its supremum 3 is 
not in the chain but does exist in the poset. We merely define 5 to be the stream such 
that S 1 - Sjf for all / € Dom{S N ) for any S N in the chain. S is well defined because the 
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S N are elements of a chain. S is infinite because the chain is infinite and the domains 
Dom(S N ) are unbounded. No element of the chain is an upper bound (given any stream 
in the chain, we can find a longer one) so S is the supremum. H 

Therefore Cpo-streams lives up to its name: it is a chain complete partially ordered 
set. Note that the finite streams in this poset constitute a basis in the sense of [MAR-76]. 
Strictly speaking, we should define Cpo-stream 8 (Data-type) and therefore have different 
posets for each kind of data. We will not do this in this dissertation, as the generaliza- 
tion is clear. Instead we will treat DFPL as an untyped language (like LISP). 



DFPL Operators as Isotone Functions on Finite Streams 

In this section, we restrict our attention to DFPL operators on finite streams because 



we 



wish to prove isotonicity — continuity is treated later. 



The simple operators, since they operate on streams element by element, are clearly 
isotone. Let Sop F be a simple tf-ary operator on streams which applies F to each 
AT-tuple of corresponding input data. We denote this by Sop^S^ ...,S N ): each function 
F gives a different simple operator. That is: 

Sop F (S l ,...,S N ) = S 

WhmS l -F{S l I t ...,S ir I ) 

ytIeL*r\j iN Dom(Sj) 

Now let S K <, Sx K , then Sx K - ( ) implies S K - < > (because Dom(S K ) = Dom(Sx K )). But Sx 
= Sop F (S { ,...,Sx ir ...,S N ) iff for a ni€Lx-Dom(Sx ir r\j 1kK Dom(S J ))Sx I -F{S x I ,...,Sx K I , 
...,S 0. Now since L S Lx, it is also the case that for all I € L: Sx 1 = F(S /,..., Sx K ,..., 
S/). But since LsDom(S K ) and S K ±Sx K , we have Ss'-FCS/,..., S/i for all I e L. 

Thus Sx 1 - S 1 for all J € L so S ± Sx. Therefore Sop is isotone in each argument. H 

i 

The operator Hold takes a constant datum C and attaches it to the front of the stream 

S. We denote this by Hold c (S): each value of C gives rise to a different Hold function. 
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We define HoW c (S)-C©S where "©"is defined as follows (with "+" representing 
ordinal addition): 

S®A-Sa 

WhereDom(Sa)-l+D<m(S) 

AndSa J »If I -I Then A Otherwise S 1 ' 1 

Thus "©"is isotone since if S, * S, then A © S, * A ®S V Therefore Hold c (S) is 
isotone in S. B 

We define another useful isotone operation "t" as follows (with "-" representing 
ordinal subtraction): 

rs-sd 

W here Dom ( Sd ) - Dom ( S ) - 1 

Obviously, "t" is isotone since if S l ^S 1 then tS, 4rS r the "©" and V operations 
are equivalent to CONS and CDR in LISP. 

The Switch operators are the most complicated functions from streams to streams. 
First we define the Outbound Switch operator Orwitch p W,D): 

Oswitch p {C,D)- 

IfC~{ WZ>-OTAen () 
IfC l -PThenD l ®Oswitck p (TC,TD) 

Otherwise Qvwitch ,(tC,tD) 

Here P is the port number, C is the control stream and B is the data stream being 
switched. Thus an Outbound Switch with three ffcfts i% 1 and 2) would require the 
three functions O8witeh (C, D), 0s»tfc*,<C,2?> and Qmiitck^G, D) for its complete 
description. 

We prove that Otwitck is isotone in the argument C by showing that if C%Cx then 
Oswitch p (C,D) ZOswitch p (Cx,&Y. The proof proceed! by induction on the finite ordinal 
D<m(Cx). Note that Cx - ( ) iff DomiCx) - {} and that Oswitch p U ),D) - Oswitck p (C, ( » 
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{ > Substituting Cx in the definition of Oswitch, we get: 

Oswitchp (Cx^)* 1 

IfCx=( )VD={)Then (> 

If Cx 1 = P Then D 1 ® Oswitch p ( r Cx , r D) 

Otherwise Oswitch p (r Cx, r D) 



We assume in the steps that follow that D is not ( >, since for any C and Cx, Oswitch p (C, 
()) = {)=. Oswitch p (Cx, ( ». The base step is as follows: Cx « ( > implies C » ( > so that 
Oswitchp(C,D)=* Oswitch p ({ ),D) = Oswitch p (Cx,D). The induction step is: let Dom(Cx) 
= N + 1; if C = ( ), then Oswitch p {C,D) - ( ) which is a prefix of any stream. If C * ( ) then 
rC^rCx and C'-Ca? 1 . Now if C" -P then: 

Oswitchp ( C , D ) - C 1 © Oswitch p ( t C, t I? ) 



Oawitch p {Cx,D) = Cx l ® Oswitch p (T Cx,tD) 

So Oswitch p (Cx,D) = C l ®Oswitch p (r Cx,r D) 

By the isotonicity of "©", Oswitch p (C, D) ± Oswitch p (Cx,D) if Oswitch p (tC,tD)-£ 
Oswitch p (rCx,rD) But rC-^rCx and Dom(rCx)^N, so we may assume, as the inductive 
hypothesis, that Oswitch p (rC, rD) ± Oswitch p (rCx, rD). Now if C 1 * P then: 

Oswitchp (C,D) = Oswitchp (t C,r D) 

Oswitchp (Cx,D)" Oswitchp ( t Cx , t D ) 

But tC 1 tCs and Dom(rCx) « iV, so again we apply the inductive hypothesis, that 
OswitchpirC, rD) £ Oswitch p (rCx, rD). H 

The proof that Oswitch p (C, D) is isotone in D is essentially identical. 

The Inbound Switch operator has N + 1 data ports D Q through D N , where we start at 
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because the simple case of D Q and Z), corresponds naturally to a True/False Switch. 

1 switch is defined as follows: 

Iswitch(C,D Q ,...,D N ) = 
JfC"() Then () 
IfC l -0AD *OThen 

D^ © Iswitch(r C,t D q , ... ,D N ) 

• • • • • 

IfC l -NAD N *()Then 

D N 1 ®Iswitch(rC,D ,...,rD N ) 
Otherwise ( > 

One can prove that I switch is isotone in each of its arguments in a manner similar to that 
Oswitch by which was proved isotone, except that the induction must be on the (ordinal) 
sum of the domains of the D r since only one is reduced by each recursion. 

DFPL Operators as Continuous Functions on Cpo-streams 

Having defined all the primitive determinate DFPL operators as functions on finite 
streams, we wish to complete them to be continuous functions on Cpo- streams. That is, 
we wish UOp(C) - Op(UC) for any chain C (where |_]<S denotes the supremum of S). 
This is straightforward since we have yet to say how a primitive operator transforms an 
infinite stream. Let Max-chain(S) - {Sj \ Sj^S] for any S, so that for infinite S, 
Max-chain(S) is the (infinite) maximal chain containing S. To make an operator 
continuous, we define Op"(S) - Op(S) when S is a finite stream, and Op u {S) - 
UOpiMax-chain(S) — {S}) when S is an infinite stream (recall that if X is a set, F(X) = 
{F(Xelt) | XelteX}). 

Theorem 4.3: The completion 0p u of Op as defined above is continuous. 

Since Cpo-streams is chain complete, the supremum exists. Since S =» 
UMax-chain(S) we have continuity on maximal chains automatically. Now consider 
UOp(C) where C is an arbitrary chain. There are two possibilities for C: it may contain 
a greatest element (if a finite stream then C is finite, if an infinite stream then C may be 
either finite or infinite) ; or C may contain no greatest element, (in which case it is an 
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infinite chain of finite streams). If C contain* a greatest element S, then Op^CS,):* 
Op«(S) for all Sj € C (by isotonicity of Op* if S it fiaite, by definition of QpH® for 
infinite S). Thus OpHS) is she greatest element of Op*«7l aadhence its supremum. 

If C contains no greatest element, C will be an infinite subchain of Max-chain(S) for 
some infinite S. Since Cpo-$trtama is discrete and since C is infinite, no finite element is 
an upper bound for C, thus S - UC. By definition of Op w (S) for infinite S, Op u (Sj) £ 
Qp"(S) for all S t € C. Now the set OpHO must be a chain because C is a chain and Op u 
is isotone. If 0p w (O is an infinite chain then it has „ ? ao fia^ upper bound so U has the 
(unique) infinite upper bound Qp?iS). But th<s«areri^ other upfier bounds so 0p u (5)- 
UOp"(C). If Op w (C) is a finite chain then it haj^jre^^ element S^"UOp a (C). By 
isotonicity of Op u , there must exist S M €C such that Op w (5 7 ) - S for all S^S^ (obvious 
for S r € C, also true for S 7 c Afo*-cfcat»(S)). Thus, S G -UQlTiMax-ckainiS)) - Op"(S) - 
UOp"(C). H 

Therefore, we have proved that for any chain C, Op*(U0 * Upp«<C), so that 0p u is 
continuous. This applies in the obvious manner to ssulti-argumeat operators. Note that 
in the case of multi-argument operators the order of takint suprema does not matter 
because the operation! of completing a poaettaae^efetending in ifotone function [Mar-76, 
Mar-77} give results unique up to isomorphism. 



Solvability of First Order Fixed-point Equations 

We have now shown that the DFPL primitive operators are isotone on streams, and 
that we can extend any isotone function on streams to a continuous function on streams 
by defining its behavior on infinite streams as abaviS. Thus*' DiFPL primitive operators 
may all be extended to be continuous functions from streams to streams, or more 
generally, from Cartesian products of stteam* to 1 (Car*e»iajr products of) streams. Now 
it is known that any system of equations involving only continuous functions over 
complete posets have a minimal fixed point solution [MJa^t*, K*a*-77J. 

Now any DFPL program graph that includes only primitive operators and no recur- 
sion can be converted to an equivalent system of aquations. • Recall that a program graph 
corresponds to a set of equations in which 4a«h data path corresponds to an equation 
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variable and each operator instance to a function instance. By use of the copy rule, a 
program graph containing usages of defined operators can he expanded into a graph 
containing only primitives and thence into a (large) system of equations. Therefore, any 
such DFPL program has a minimal fixed point solution, that is, an assignment of streams 
to the data paths which are the overall result of "running" that program (perhaps 
forever) starting with empty data paths. 

Note that the solution obtained is a configuration of data streams and thus repre- 
sents a particular resuh of applying the function represented by the spirogram, rather than 
the function itself . For this reason, we call this a first order ftxed-poiht. 



Examples of First Order Fixed-points 

Figure 4.1 shows a simple DFPL program with a loop, far which we wUl compute a 
first order fixpoint. The Bold operator is as discussed earlier. Tito Svery mother operator 
delivers as output every other element of its input stream. For example EvvryothtiiU , 
B,C,D , E, ...»-U , C* E ,...). We will not explore the innards of this operator, they are 
not germane to the fix-point computation. To solve fins loop, we cut it at the point 
labeled X, then we solve the equation X - Ev^ryothtr(Hold B (Hold A (X))). We do this 
by applying the standard fix-point rule, computing U{x,F(i.),f (JT(x)), ...}. 

Proceeding by this rule we start with Hold A {{ » *- U )» Hold B «A » ■ - <B , A ) and X, - 
Every-othtrUB , 4»«<B). Note that this is the first approximation to X, not the first 
element of X which would be denoted X 1 . The second approximation is X 2 * 
Ev«ry-otker{jaold a (Hold A (X x y)) - Ever^otktr(Hold B lHold A {(B)})) - Every-otkeH(B , A , 
B»-(fl,B). The third approximation is X 3 » Ev9ry~0kf?(Hold B (Hold A (#^- 
Every-other(Hold B (Hold A (iB , B»)) - Evtry-otk*r((B ,A, fl , fl» - <B * 8). Thus we 
have converged after three iterations (X-X 3 -X 2 ). We can also derive the fix-point 
values of Y and Z. To wit, Y - Hold A iX) - U , B , fl> and Z - Hold B (Y) « <fl , 4 , B , B>. 

We could equally well have cut the loop at Y or Z. Then we would have solved Y - 
Hold A (Every-otkeHHold B (Y))) or Z - Hold B (Hiold A (Every-othMZ))> respectively. 
Either of these approaches would have given the same results for X, Y and Z. 
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It is very important to remember that the iterations involved in computing a (first 
order) fix-point are not the same as the iterations implied by executing a DFPL program 
loop. In computing the fix-point, we are "standing outside of time" and considering the 
data streams as wholes, whereas in executing the program loop, we are observing the 
data streams develop within time. This is analogous to the solution of equations in 
physics: the iterations necessary to solve a dynamical equation do not take place within 
the time expressed by that equation. 
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A Partial Order for Non-Determinacy 



Introduction 

We have seen that streams of data, partially ordered by the prefix relation, form a 
domain upon which determinate DFPL operators are continuous functions, so that the 
function computed by a DFPL program may be determined by means of function com- 
position and computation of fixed-points. Our task now is to find a domain suitable to 
both determinate and non-determinate operators, that is, a domain in which both kinds 
of operators may be cast as continuous functions. Part of our task however, is to 
formulate the domain and functions in such a way as to be compatible with the determi- 
nate formulation. That is, there must be a morphism from the general system to the 
determinate one, mapping the determinate functions in the general system to corre- 
sponding functions in the determinate system, and mapping "determinate" elements of 
the general domain onto corresponding streams in the determinate domain 
(Cpo-atreams) . 

Just as determinate DFPL programs may be viewed as functions on input streams and 
output streams, it is reasonable to view non-determinate programs as relations from 
input streams to output streams. Unfortunately, if we take this point of view, we lose 
the fixed-point theory which is based on continuous functions (although we Still have a 
useful notion of composition for relations). The way out of this problem is to apply the 
well known "functor" which transforms relations on sets of objects into "equivalent" 
functions on sets of sets of those objects. Therefore, for the rest of this dissertation we 
shall characterize non-determinate programs as functions from sets of input streams to 
sets of output streams. Each stream in the set corresponds to one possible execution 
Each possible execution of a non-determinate program causes a particular stream, 
chosen from the set of streams, to appear on a particular data path. If the program is 
determinate, then only one stream can appear, so the set is a singleton. Thus the natural 
map between the determinate and non-determinate semantics involves mapping a stream 
to the singleton set containing that stream. 
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Counterexamples to "Posets" on Simple Sets of Streams 

The exact choice of what kind of set of streams, as we shall see, is crucial to the 
formulation of a reasonable denotational semantics of DFPL. The obvious choice of a Mt 
of streams is just that, a set of streams. If we use this as our domain, the question is 
what partial order is suitable. The obvious choice for a partial order on sets is the 
inclusion relation, which is even chain complete. A moments thought, however, shows 
us that this is unsuitable in that it does not reduce, when applied to singleton sets, to the 
prefix order on streams. For example, the stream U> is a prefix of the stream U . S), 
but the singleton set {U» is not a subset of the singleton set {<A . B)}. Thus the subset 
relation is not a compatible partial order. 

To have a compatible partial order, the ration between two singleton sets of 
streams must reduce to the prefix relation on those tup streams. The obvious extension 
of this to non-siagteton sets is to say that streams in the first set are matched with 
streams in the second and the first setisless than the second iff the prefix relation holds 
on all the matehed streams. Furthermore, out iatttitipn tells us that one set of streams 
can be "S" than another in two ways: first, as indicated above, the streams in one may 
be prefixes of the streams in the other; second, the bigger set may simply contain more 
streams. ' 

This suggests the following attempt at a partial order, a set of streams Sa\ is "S" 
than a set Sa 2 iff for all streams S, in S. |t there exists a stream S 2 in S» 2 such that S, is a 
prefix of S r Unfortunately, this is not a partial order but only a quasi-order, since it 
does not obey the antisymmetry rule. Consider S«, -{(4), U , 4>} and Ss, -{U.*tt 
Here we have both Ss^S*, and S« 2 SS* t but clearly Ss^Ss r One way around this 
difficulty is to form the equivalence classes of sets of streams which are both "5" and 
"<>" to one another. This constructs a "quotient" system in which "<" is guaranteed to 
be a true partial order. However, in this quotient domain the semantic equations can 
only be solved to yield equivalence classes, (i.e. sets of "equrviient" sets of streams) 
which might not be enough detail for our nefeds. 

We now observe that the trouble with the previous alleged partial order was that it 
allowed us to match two different streams in S» i with a singje stream in S» r Also, our 
intuition tells us that each element in a set of streams corresponds to a different execu- 
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tion of the program, and since programs should be isotone functions, feeding a program 
a "bigger" input should not reduce the possible executions. That is, it should not be the 
case that {(A) , (A , A)} £ {(A)} . In response to these points, we make another attempt at 
a partial order: Ss l < Ss 2 iff there is an injective map from Ss, to Ss 2 such that each 
stream in Ss i is a prefix of its image in S« 2 . Unfortunately, this too turns out to be only 
a quasi-order: consider the infinite sets Ss, « {(A), U , A , A), (A , A , A , A , A), ...} and 
S« 2 -{U,4>, (A, A, A* A), (A, A, A, A, A, A), ...}. We can match (A) with (A ,A), 
(A t A , A) with (A , A , A , A) etc., discovering that Sa l < Ss v or we can match (A , A , A) 
with (A, A), (A, A, A, A, A) with (A , A , A , A) etc. (omitting <i4» and find that S*, > 
Sa v But this would imply that S», is equivalent to Ss 2 , which is unreasonable, since they 
have no elements in common. It does not help to demand that the map from one set of 
streams to another be bijective, since then sets of unequal (finite) size would be incom- 
parable. 

The following scenario suggests that we wish Sa i to be strictly less than Ss r 
Consider a non-determinate program that operates as follows: it produces an indetermi- 
nate, but even (including zero), number of A's on its output port, then copies its input 
symbols to that output port. Therefore, when presented with the input stream B, its 
output is (B) or (A , A , B) or (A , A , A , A , B) etc.; when presented with the input 
stream (A), its output is (A) or (4 , A , A) or (A,A,A,A,A) etc.; and when presented 
with (A , A ), its output is (A , A) or (A , A , A , A) or (A t A , A , A , A , A) etc. More 
precisely, when applied to the input set {(A)}, it produces 5s, above, and when applied 
to the input set {{A , A)}, it produces 5« r Since our intuition tells us that the set {(A)} is 
strictly less than {01 , A)}, and since we wish all DFPL programs to be isotone, we must 
say that the output set Ss x is strictly less than Ss 2 , for they are clearly not equal. 

There are a number of other possible contenders for a partial order on sets of 
streams. One which actually is a partial order, and not merely a quasi-order, defines Ss, 
< S* 2 iff there exists an injective map from Ss 1 to Ss 2 such that each element of Ss^ is less 
than its image in Ss 2 , such that the image of the map is a closed below subset of Sa 2 (i.e. 
whenever X is in the subset, so are all Y < X), and such that the map is co-isotone (i.e. 
F(X) < F(Y) implies X < Y). Unfortunately, not all DFPL operators are isotone in this 
partial order, so it too is unsuitable for our purposes. In fact, we conjecture that there is 
no suitable partial order (if we restrict ourselves to plain sets of streams) which does not 
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require using equivalence classes of sets of streams, which reduces to the prefix order on 
singleton sets, and in which all primitive operators are isotone functions. 



Another Problem with Simple Sets of Streams 

Consider the DFPL program in Figure 5.1. ft consists of two two-input Arbiter's 
whose outputs are connected to the inputs of a simple primitive AM operator. If the 
input streams to the Arbiter's are, as illustrated* the singletons (2) t ,C*V<i») and < 5), then 
the Arbiter's outputs are the sets {(2,3), (3 , 2 )} and .{<*> 5 > , (5 , n)} s Which are also 
the inputs to the sides of the adder as shown. Now, since my determinate operator 
must, if confronted with sets of input streams, combine each stream element of each set 
with every element of every other (i.e. it must operate on the Cartesian product of its 
input sets) the output of the adder must be the set {(6 , 8), {7 , 7), (8 , 6)}. Note that 
the stream (7,7) would be generated twice but would only appear once, because the 
output is a sit. 

Now consider the DFPL program in Figure 5.2. It consists of a single two input 
XrMter whose output m connected to 6<wA inputs Of the smiple primitive Add operator. If 
the input streams to the Arbiter are, as illustrated, the singletons (2) and (31, then the 
Arbiter's output is the set {(2 , 3) , (3 , 2)}, which is also the input to both sides of the 
adder as shown. Now, by the Cartesian product riile we used above, the output of the 
adder would be{(*,6>,(5,5),(6,4)}. This, unfortunately, is a result which the 
operational semantics of DFPL contradicts — the stream (5 , 5) can never be a result of 
this program. The Arbiter either outputs (2 , 3) or (3 ,2), it can never output both 
together nor can it output their average! 

This example demonstrates that simple sets of streams is not an adequate basis for 
the denotational semantics of even very simple programs not involving fix-points. Such 
simple sets just do not contain enough information to allow such programs as Figure 5.1 
to be distinguished from programs like Figure 5.2. In particular, the adder operator has 
no way of knowing whether its inputs came from the same or different Arbiter's. Thus 
we feel justified in searching for a somewhat more complicated basis. We must incorpo- 
rate in each stream an indication of how it may have been arbitrated. 



-43- 



Sets of Tagged Streams of Data 

It is possible to obtain a straightforward partial order by considering sets of tagged 
streams of data. Each datum in each stream in the set has associated with it zero or 
more tags, each of which identifies the sequence of arbitrary choices made by a non- 
determinate operator which contributed to the existence of that datum in that stream. 
Sets of tagged streams are constrained in the following two ways. A later datum may 
never be the result of fewer non-determinate choices than an earlier datum, and no 
stream is merely an approximation to another. 

Two sets are compared by matching each stream in the first set with a stream in the 
second set such that the first stream is a prefix of the second stream. The prefix relation 
used here is the same as that used in Cpo-streama, except that the items in tagged-stream 
are pairs of Data and Tag-set, rather than merely Data. However, all the relevant 
properties apply to tagged-streams. This relation may be shown to be a true partial 
ordering of sets of tagged streams, and the resulting poset is chain complete if infinite 
streams and sets are admitted. 

Each instance of an Arbiter in a DFPL program is uniquely identified by its 
Arbiter-name, an element of set with equality. Remember that each recursion level 
generates new instances of its operators. A Choice' sequence of an Arbiter is an empty, 
finite or infinite sequence of integers, chosen from range through Number-o j -input- 
ports - 1. A Choice-sequence represents, in order, the non-determinate choices made by an 
Arbiter. A Tag is a pair {Arbiter-name, Choice-sequence), and represents the choices made 
by a particular Arbiter. A Tag-set is an empty or finite set of Tags such that no two 
elements have the same Arbiter-name component. A tag-set represents the non- 
determinate choices made by a set of Arbiters. The restriction that no two elements 
have the same Arbiter-name insures that no tag-set represents that an Arbiter has made, 
self -contradictory choices. A tag-set Ts z is said to be an Extension of a tag-set Ts, iff 
there is an injective map from Ts x to Ts z such that for each element of Ts { , the Arbiter- 
name of that element is the same as the Arbiter-name of its image, and the Choice-sequence 
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of the element is a prefix of the Choice- sequence of its image. More precisely, we say 
that: 

TgsZTgex* 

IMapiTgs-Tgex: 
Injective { M ap ) A 
VTgeTgs: 

Arbiter-name i.Tg)» Arbiter-name (Map{Tg))/\ 
Choice-sequence (Tg)^Choice-»equence(MapiTg)) 

A Datum is an element of some set of data. All data are assumed to be incomparable 
from the denotational point of view. A Tagged-stream is an empty, finite or infinite 
sequence of pairs of the form (Datum, Tag-set) which obeys the tag-set extension rule. 
This rule demands that the tag-set component of any element tn the tagged-stream is an 
extension of the tag-set component of all elements preceding it in that tagged-stream. 
This insures that no datum is the result of fewer aon-determinate choices than a datum 
which occurred earlier in that tagged-stream. A Tagged-str eam-set is a non-empty set of 
tagged-streams which is Prefix-reduced. This means that no tagged-stream is a strict 
prefix of any other tagged-stream in the tagged-stream-set. This insures that no tagged- 
stream is merely an approximation to another in the same tagged-stream-set. 

For example, die result of supplying a two port (non-determinate) Arbiter with the 
(determinate) inputs {(A)} and {<&)} yields as output the (non-determinate) tagged- 
stream-set {<Ao t Boi),(£i» .Ai»>|. The result of passing that set through a 
(determinate) operator which throws away input data until an A appears, whereupon it 
copies the rest of the stream to its output port* is |U «, B<u), Ut»)}. 

The partial order on tagged-stream-sets may how be difmed. A tagged-Stream-set 
Tss\ is £ a tagged-stream-set Tss 2 iff there exists an injective map from Tss x to Tsa 2 
such that each element of Tss, is a prefix of M image in tss r Mote that this implies 
that the cardinality of Te* { is no bigger than ikat of fitj. Also note that thM is equiva- 
lent to saying that Tss, «j Ts» 2 iff for all elements #f *»sy tae^&dstsan element of Tss 2 
of which it is a prefix. This may be shown as follows. If So, Sb and Sc are streams such, 
that So is a prefix of Sc and Sb is a prefix of Sc, then either So is a prefix of Sb or Sb is a 
prefix of So. This implies that if there exists an element S 2 of Tss 2 of which an element 
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So, of Tss, is a prefix, then there is no other element Sb l of Tss l which is also a prefix 
of S 2 , otherwise, either S6, would be a prefix of Set, or vice versa, and we disallow this in 
the definition of tagged-stream-set. 

The map which takes a stream S into a tagged-stream-set Tss - {St} such that St 1 "* 
(S 1 , { } > for all J e Dom(S), is an monomorphism of posets. This will become clear in the 
next two sections, justifying our implied claim of a non-determinate domain which is 
compatible with the domain Cpo-streams. We shall see later that the Tags have another 
use besides allowing the definition of a compatible partial order. 

The way that the tags force the tagged-streams of one tagged-stream-set to be 
compared with particular tagged-streams of the other tagged-stream-set is reminiscent of 
the "arrows" in Lehman's categories which he uses to model domains for non- 
deterministic fixed-point semantics [Leh-76]. 

Proof of Partial Order 

Theorem 5.1: The relation "3" is a partial order. 

To prove that "*i" is a partial order on tagged-stream-sets, we must prove that it is 
reflexive, transitive and antisymmetric. Reflexivity is obvious: take the identity map as 
the injection of Tsa } to Tss v Since any tagged-stream is a prefix of itself, we have Tss { 
3Ts8 r 

Transitivity is almost as simple. Given an injective map Af, from Tss^ to Tss 2 , and 
an injective map M 2 from Tss 2 to Tss y we know that the composition Af 2 » M , is an 
injection from Tss, to Tss y Then, since the prefix relation is transitive, we know that 
every element in Ts8 x is a prefix of its image (under M 2 ° Af,) in Tss y Thus "sf * is 
transitive. 

Antisymmetry is the most difficult property to prove; it is the property which the 
alleged partial orders discussed earlier lack. Let Af, be an injection from Tss { to T$s 2 
and M 2 be an injection from Tss 2 to Tss v We can immediately conclude that T««, and 
Tss 2 have the same cardinality and that M 2 ° M, is a bijection from Tss { to itself. Each 
element of Tss, must be a prefix of its image in Tss, under M 2 « Af,, but due to the 
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constraint on tagged-stream-sets, no element can be a prefix of another. Hence the 
image must be the element itself so M 2 » M, must be the identity. Now we observe that 
each element of Tss, is a prefix of its image in Taa 2 under tt v and that element in fit i 
is a prefix of its image in Tn t under M r But tb* image under M^ix the original element 
in jPss,, so the element in Tmt 2 is equal to the element in $** x b$ aniisiOTmetry of the 
prefix relation, Therefore, T»» 2 is equal to Tsa^and "^Vis aa*isyjiunetric. B 

Proof of Completeness 

Theorem 5.2: The partial order "jfis (countable) chain complete. 

To prove thia, we mast show that any countable chain has * supremum. Let {Taa^ 
Taa 2 ^ Taa 3 £ ...} be such a countable chain, aad -te-iitf j*4^>< Jvbe, the associated 
sequence of injective maps which specify the relations (i.e. M,: Tm, - T'»« 2 , M 2 : Taa 2 * 
r8« 3 etc.). Let S be an element of T»« y , then the set ' {S,AT^(S),3f w « Af^ ,(£),.., J 
forms a chain under the prefix order. Since Cpo-atraama is chain complete, this set has 
a supremum which we call S-aup. CaU the set of all such suptema, Taa-aup. Since all 
the itf's are injective, and each Taa is prefix-reduced, we apply Lemma 4.1 to deduce 
that each element S of a taa belongs to exactly one stich chain, for each T«* w , define 
Af«ttp y to map each element S into S-iup, the supremum of i*i clhtih. The suprema of 
all distinct chains are themselves distinct (by Lemma 5.1 and the assumption that Tss's 
are prefix-reduced) because each chain has at least one non-supremal element not the 
other chain. Then we have that Maup^: Taa^ ^ T,aa-av$ is an injective map which 
establishes that Taa N <£ Taa-aup. But N was arbitrary, so T***«*f is an upper bound for 
the chain of Tss's. 

If there were another upper bound, call it tas-ntb, for the chain of T»'s which was 
strictly less than Taa-aup, then there would be an element S-ub in Taa-ub which was a 
strict prefix of an element S-aup of Taa-aup, or there would be an element in Taa-aup 
which had no prefix in Taa-ub. In the first case, S-ub would be an upper bound of some 
chain, but S-ub < S-aup, contradicting the fact that S-aup was the supremum of that 
chain. In the second case, there would be a chain of elements from the Tss's which had 
no supremum in Ts8-ub, hence Taa-ub could not even be an upper bound. Therefore, we 
may conclude that Taa-aup is indeed the supremum of the Tss's. 
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It remains to be shown that Tss-sup satisfies the extra conditions on tagged-stream- 
sets: namely, that no tagged-stream is a strict prefix of another, and that within an 
tagged-stream, the Tag-set on a later item in the tagged-stream must extend the Tag-set 
on an earlier item. We prove these additional properties by contradiction. 

If one tagged- stream, Ts,, were a strict prefix of another, Ts 2 , then all the elements 
of the chain of which Ts, was the supremum would be in the chain of Ts 2 , hence Ts } 
could not be their supremum. 

If the tag-set extension property were not obeyed, then there would exist a tagged- 
stream Ts-sup in Tss-sup such that Tag-set(Ts-sup K ) did not extend Tag-set(Ts-sup J ) 
(where J < if). But, since Tss-sup is the supremum of its chain of Tss's, there would 
exist some Tss N which contained a tagged-stream Ts £ Ts-sup such that Ts J « Ts-sup J 
and Ts J - Ts-sup J contradicting the tag-set extension property assumed for the Tss's. 

Therefore the Tss-sup is a proper tagged-stream-set and is the supremum of the 
Tss's, which means that the set of tagged-stream-sets is a complete poset. g] 

Satisfaction of Previous Counterexamples 

As we have just proved, the set of tagged-stream-sets form a chain complete 
partially ordered set (not merely a quasi-ordered set). Also, we have shown how the set 
of tagged-stream-sets is compatible with streams under the map which takes a stream S 
into the singleton set consisting of the tagged-stream whose Data are the same as S, and 
whose tag-sets are empty. Therefore we have satisfied the two generic counterexamples. 

The specific counterexample involved a non-determinate program which had two 
states: produce A's (state 0) and copy input (state 1). Using the history of these states 
as the Choice- sequence attached to each output datum (and since there only need be one 
Arbiter, omitting the Arbiter-name and set brackets from the tag-set), we get the 
following specification of the program: an input of {(A)} gives rise to the output: 

{ (4i ) , {Ao , A oo ,4ooi) , {Ao , A oo , Aooo ,i4oooo , 4ooooi ) } 

whereas an input of {{A , A)} gives rise to the output: 

{(Ai ,i4n), {Ao , A oo ,i4ooi , 4oou ) , {Ao , Aoo , Aooo ,4oooo ,j4ooooi , 4ooooii ) } 
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The rules for match tagged-streams in one tagged-stream-set with those in another make 
it quite clear that the first output is «S the second. 

Referring back to Figure 5.2 now, we see that the Arbiter's output streams would 
be tagged as follows: (<2o, a.t).(3»..2i.)}. Let us adopt a modified Cartesian prodngt 
rule, to be detailed in the next chapter, that tuples of input streams are combined by an 
operator only if their Tag. are Comtfetemt. Then the output of the adder would be the 
tagged-stream-set {{** , B.t). (6, , »».». The stream <5 , 5) cannot appear at all in the 
output set because it* first element would fcave to *«t»§g*MH>th and 1. This is 
impossible since it would mean that the ArHt# : >m*d# tw* *m«tu*Hy exclusive decisions 
at once. 

In summation, we have constructed a domain for non ; determinate semantics that 
satisfies all the objections we discovered to the earlier approaches. 
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-6- 
Semantics of Non-Determinate DFPL Programs 



Overview 

In this chapter we develop the fixed-point semantics of full DFPL with both the 
determinate and non-determinate primitives. We have shown, in Chapter 5, that the 
domain of Taggtd-atraam-aeU is suitable for fixed-point solutions of programs. We must 
now show that the DFPL operators are continuous on this domain. To do this, we first 
develop some helper functions on tag-sets, then we show how the determinate operators 
are extended to tagged-stream-sets, then we can show that the determinate operators are 
continuous. Next we precisely define the non-determinate Arbiter and prove that it is 
continuous also. We can therefore deduce that all (recursion free) DFPL programs have 
a well defined behavior no matter what inputs they receive. We conclude with an 
example of a simple fixed-point computation of a non-determinate program containing a 
loop. 



Notation 

The notation used in this chapter is somewhat complicated and thus is outlined here. 
Variables are written out programming style (i.e. multi-letter abbreviations) as in earlier 
chapters, but there are more possibilities. Variables consist of a head (usually an 
abbreviation), which connotes their domain, an optional body followed by an optional 
tail, which identify the particular variable, and an optional subscript, which identifies 
one of a group of similar variables. Commonly appearing heads are: Ta for a tagged- 
stream, Taa for a tagged-stream-set, Tg for a tag and Tga for a tag-set. The common 
optional bodies are: -a-, -6-, -c- and -d-, where -a- and -b- connote arbitrary distinct 
variables, -c- and -d- usually connote control and data inputs respectively, and lack of a 
body usually connotes an output variable. An tail -* usually connotes extension of a 
stream or set, that is Ta-£ Tax, Tga £ Tgax etc. Some examples are: Taa for an output 
tagged-stream-set, Tadx t for the 7th extended data input tagged-stream, Tgax for an 
extended tag-set, and Tga for an arbitrary tag. 
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In the interest of brevity, we often apply a function to a set of arguments without 
writing it out explicitly. For example, if F: X x Y ■* Z, we write F(Xs, Ys) (where Xs s 
X and Ys s Y) instead of {F(Xa, Ya) \ iXa, Ya) eXsx Ys}.. In general, if a function takes 
an element of some domain as an argument, we may apply that function to a set of such 
arguments implying that the appropriate set of results is denoted. Note that the original 
domain may have sets as elements, in which case we would apply the function to a set of 
such sets. 



Tag-set Functions and their Properties 

In order to define the extensions of the determinate operators (Hold*, Sop 6 , 
Oswitch* and Iswitch*), we define some helpful auxiliary functions. First of all, we 
define some access functions which allow us to take components of Tagged-streams and 
Tags in a clear manner: 

Datum(Ts) = Ts 1 
Tag-set(Ts)*Ts 2 
Arbiter-name » Tag 1 
Choice-sequence » Tag 2 

The next function, Consistent-tags, is a predicate which is true of unions of tag-sets 
which are consistent, that is, tag-sets which do not contain Tags with the same Arbiter- 
name but Choice-sequences which are not prefixes of each other (i.e. Choice- sequences 
which do not form a chain) : 

Consistent-tags ( Tgs x , . . . , Tgs N ) s 
"iTga,Tgb€\} IiN Tgs I : 

Arbiter-name ( Tga ) - Arbiter-name ( Tgb ) ♦ 

Choice-sequence ( Tga ) <J Choice-sequence ( Tgb ) V 
Choice- sequence ( Tga ) ^ Choice-sequence ( Tgb ) 
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The last helpful auxiliary function is related to the previous., it » the Merge-tags 
function, which merges the Tags in a consistent tag-set union to yield a tag-set which 
contains, for each Arbiter-nams, the maximal €ko&e*equ*im from the input Tags: 

Merge-tags(Tgs x ,...,Tgs N )" 
{ Tg € \J IiN Tgsj I 
VTgaeV lsN Tg» z : 

Arbiter-Hams (Tg)" Arbiter-name ( Tga ) ♦ 
Chrtce-*equence(Tg)ilCka4^8squeiw(fga)} 

The Msrgs-tags function is used to generate the tag-sets for the outputs of opera- 
tors given their input tag-sets. The Consistent-tags function is used to assure that 
operators do not process any input streams which are inconsistent with each other (cf. 
Chapter 5, especially Figure 5.2 and related text). 

Lemma 6.1: Both Consistsnt-tags and Msrgs-tags are commutative and associative 
functions. That is, F-tags(Tg so, F-tagsiTgsh, Tgsc))~ F-tagsiTgsa, Tgsb, Tgsc) - 
F-tags(Tgsc,F-tags(Tgsa f Tgsb}) - (where F-tags is Consistsnt-tags or Msrgs-tags). 

This follows directly from the definitions. 

Lemma 6.2: If Tgs C Tgsx then Consistent-tagsiTgs, Tgsx) is Trus. This too follows 
directly from the definitions of "C" and Consistsnt-tags. 

Lemma 6.3: If Consistsnt-tags(Tgs v ...,Tg* T , ..., TgsJ is False, then for any J and 
any Tgsz t such that Tgs t £ Tgsx v Consistsnt-tagsiTgs^ ..., Tgsxp ...,Tgs H ) is also FaUm. 
Expanding the definition of Consistsnt-tags{Tg8 i ,... 1 Tgs I ,...,Tgs lf ) we find that it is 
False iff: 



3Tga,Tgbe\Jj iN TgSj: 
Arbiter-name ( Tga)" ArUtsr-name iT0)>f\ 
Choice-sequence ( Tga ) 4 Choice-sequence (Tgb ) A 
Choice-sequence ( Tga ).. j£ Choice-sequence i Tgb ) 
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Now recall the definition of "£": 

Tgs^TgsX;* 

3 Map : Tgs { — TgsXj : 
Infective ( Map ) A 
VTgeTgaj: 

Arbiter-name (Tg) = Arbiter-name ( Map (Tg)}A 
Choice- sequence (Tg)-£ Choice-sequence (Map (Tg)) 

Now if neither the Tga or the Tgb which falsified Consistent-tags( Tgs ,,..., Tgs p ..., 
Tgs N ) is an element of Tg» r then Conststetti-tajrsCTsrs,, ...,.Tg*x p ...,Tgs N ) is trivially 
Fa/*e also. If, however, either Tga or T^fc is an element of Tgs T then its image in Tgsx { 
under M ap serves as a counterexample to Conststeni-ta^Tjrs,, ...,Tgsx p ...,Tgs N ) (due 
to the properties of "£"). S 

Lemma 6.3 assures that the tagged-streams which result from the operators defined 
recursively in the next section are well behaved in the sense that if the recursion is 
terminated by Consistent-tagsi...) becoming False, there are no elements farther down 
some input stream which might contribute to the output, if only they could be reached. 
That is, the recursive definitions do not disallow any realizable behavior. 

Lemma 6.4: If TgsXj £ TgSj then Merge-tags(Tgs x , ..., Tga p ..., Tg» s ) C 
Merge-tags( Tgs x ,..., Tgsx p ..., Tga y ). Recalling that: 

Merge-tags ( Tgs , , . . . , Tg 8, ,...-, Tgs N ) - 
{ Tg € [J JiN Tgs j \ 
VTgaeVj^Tgs/. 

Arbiter-name (Tg)" Arbiter-name ( Tga ) * 
Choice-sequence (Tg)4 Choice-sequence ( Tga ) } 

We immediately derive that: 

Merge-tags ( Tgs x , . . . , Tgsx x , . . . , Tgs N ) - 
\Tgx€ TgtjWj+jTgSj I 
VTga€. Tgs^Kjj^Tgsy. 

Arbiter-name ( Tgx ) - Arbiter-name ( Tga ) ■*• 
Choice-sequence ( Tgx ) 4 Choice-sequence ( Tga ) } 
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Let Mtg-Merge-tags{Tg» i ,...,Tgs I Tgs N ) and Mtgx - Merge-taga(Tga ,,..., Tgax r ..., 

Tga N ). To show that Mtg C M tgx we must construct a map Mtmap: Mtg -> Mtgx which 
satisfies the definition of "C" above. Let Tg e Mtg, Tgx € Mtgx and Tgx - MtmapiTg). 
Now define Mtmap as follows, if Tg e T^ where J**/» then Tgx-Tg, but if Tgf € T^s, 
then TV* - MapiTg) where Mop is the map which makes Tg» r C fysas, as above. 
Obviously ilftwop satisfies the second (quantified) part of the definition of "G" since 
both Map and the identity do, so we only need show that Mtmap is injective. Let Tga # 
Tgb be arbitrary elements of Mtg and let ■£, gax and 2>S¥he tlwtir images under Mftnap. 
Note that neither Tga 3 Tgb nor Tpd 1 1^a can be true beWitoe e¥ the definition of Mtg. 
If neither Tya nor Tgb are in T^ then 2>*b* Tga iM Tgb*- Tgb «» 2V***»T#te since 
Mtwap is the identity except on Tg$ r SinmWy, if both Tfro and tgb are in Tg** P then 
Tpaa* r^te because Mtmap -Map when restricted to Tgxcj and Map is assumed injective. 
The interesting cafes are when Tga « Tg* t and Tgb£T0*j or vice-versa. In the first 
case, Tgb*- Tgb and T§w m M*p{T8*Y But by the asswiiprtoo that Map shows how 
rjjsj C Tg*x v we know that C*o^««^«*^ffei£^ the 

properties of "*" and sequences, and by the fact that Tga 4 Tgb and fyi* Tga, we see 
that 2V& * T?o* and hence that 2ty*» .# Tga** Tfeefffor* Mttwip ,is injeetive and Mtg C 
Mfflrx. IS 

Lemma 6.5: If Tga Z Tgax then Merge-togaiTg^ T#ax) - r#«*. Substituting in the 
definition of Merge-taga, we get: 

Merge-taga ( Tflrs , Tgrs* ) - 
{Tg € TgaKlTgax \ 
VTgae TgaUTgax: 

Arbiter-name (Tg)- Arbiter-name (Tga)* 
Clwice-»equenee{Tg)4Chowe'ietptenee{Tga)} 

If Tff e Tys then 3Tgx e Tgax: Tg < Tgx (because Tga C Tgax) so no elements of Tga 
contribute themselves to Merge-taga(Tga, Tgax) unless they also are in Tgax. Therefore 
Merge-tagaiTga, Tgax) - Tgax. H 

Lemma 6.6: If Conaiat&nt-taga(Tg*u i Tg*b) then TgaaZMvrg&tag8(Tgaa,Tgab), and 
symmetrically, Tflraft £ Merge-taga(Tgea, Tgab). 
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Consider all pairs (Tga, Tgb) e Tgaa x Tgab. If Arbiter-name(Tga) »* 
Arbiter ~narM(Tgb\ then both get included in M«rgt-tagi(TgM, Tgsb). U 
ArbiUr-nameiTga) - Arbiter-nameiTgb) then the one tiiaVisthtf prefifc of the other (and 
one is since the sets are consistent) gets diic*r<ied* n in ■ the construction of 
Marge-tagaiTgaa, Tg*bi. Since both Tg$a and Tgab have only one occurrence of each 
4rmar-7Mm», we can stop after. consideijin| each pair, no further prefixing cm obtain. 
Hence each Tga either itfjslf appears in Mfrgt-tagtiTgsa, Tgab) or a Tgb of which it is a 
prefix appears. Therefore, by the definition of "C", we see thatfysaC 
Merg*-taga(Tg8a,Tg«b}md*ymmettic»My.%L , : 

Extension of Determinate Qperator» r 

The HoW operator fr the simplest operator 8 ttr '-feftiad ''lb tagg ed-streatn-s«ts. It is 
defined as follows: --i*-^-^ 

JfoW c «( Tss ) - { Tsa € Hold c u ( Tsa ) 1 V r#6 c ifott^ ( 2to): rimVfrM ' ' '' ' . 

fNb#r»HofaI c r(r«)- 
If Dom < Ta J < u Tkm Hold c ( Ta) OOmrutM U Tt/<Tt 8otd c ( Taf) 

Wterp : <JjMd- c ( T» ) - (C,, .| i)#^ * 

That is, Hoid c HTs$)M the act of all tagged-streams from 7*«« wfdv the additional item 
"empty-tagged C" atpicfcSd to ^ ( f^^'«JllJMiM^iMMM^^t' Is reduced to eliminate 
strict prefix*** But smce 7*» is already Pw/#*fva^#e^ and since the extension of "©" 
is trivial, we «msimpHfy the definition to: t 3; 

Note that since any tag-set extends the empty tag-set, the tagged-streams in H<M c KTaa) 
obey the tag-set extension rule. Note also that the uneatended HteM function here is 
very similar to the Hold function in Chapter 4: 

To simplify the definitions of the remaining DFPL operators, we define once and for 
all the completion Op u of an operator Op. Namely: 

0p u {...,T8 l ,...,Ta tr )-U0p<Ca(T$ i \,...,Ca(Ta N )) 
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Where Ca(Ta)- 
lfDom{Ta)<wThen{Ta\ 
Otherwise {Tsa \ Taa<Ts} 

This definition is the obvious generalisation of the one usedabove in the definition of 
HoldJ" and is equivalent to the definition used in C&afftelf 4. 

Lemma 6.7: The completion 0p» of an isotoae operator Op* as defined above, is 
continuous on its Tagged-atraam arguments. v 

The single "LT is well defined because the codomain of Op is the set Tagged- 
«tr«m«.which U o-chain complete and the set QpLCatf*^ .... Ctgf^) is directed and of 
cardinality no bigger than « [Mar-76, Mar-77]. The proof is thus the obvious jeneralka- 
tion of the proof of Theorem 4.3, substituting directed sets for chains and the domain 
Taggad-atrtama for Cpo-strtem*. 

Now we can define the extended Simple Operators. The extended Simple Operator 
Sop^« of N arguments and one parameter F (the function to be applied), essentially 
takes the Cartesian product of its input tagged'Stteam-sets and applies the stream 
operator Sop F to each element thereof to get an output ta*ged*stream-set, from which 
strict prefixes are eliminated (Prafix-reduetio*). However, whenever Sop F finds 
tag-sets which are mutually inconsistent, it ceases processing that particular tf-tuple of 
input streams, truncating the output stream accordingly. This insures that F is not 
applied to any data which could not coexist under a particular sequence of non- 
determinate choices. The precise definitions of Sop,, 4 and Sop F are: 

Sop F *(rss,,...,r«« y )- 
- {Taa€Sop F u (T$s i ,...,T88 N ) I 

V Tab € Sop/ ( T«8j , .. . , Taa N ) : Taa * Tsb } 
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Where Sop F ( Ts ,,..., Ts„ ) - 
// 3lSN:T Sl -{)Then (> 

If Consistent-tags ( Tag-set (Ts ,'),... , Tag-set ( Ta^' ) ) TAera 
(^(£>otttTO(rs / 1 ) , ... ,Datum( Ts N l )) , 

Merge-tags ( Toy-set (Ts, '),... , Tay-set ( Ts^ 1 ) ) > © 
Sop f ,(Trs I ,...,Trs^) 
Otherwise ( ) 

Next we define the extended Outbound Switch operator. The Oswitchp* operator 
takes two arguments: the control tagged-stream-set, Tssc, the data tagged-stream-set, 
Tssd, and one parameter, the port number P. This parameter is necessary since the 
Outbound Switch is an N output operator, and mathematical notation does not directly 
allow such functions. Oswitchp* essentially applies Oswitchp to each pair of input 
tagged-streams in the input tagged-stream-sets, and then Prefix-reduces the resulting 
set. Again, Oswitch p stops processing its input streams whenever it finds two tag-sets 
which are inconsistent. The precise definitions of Oswitchp* and Oswitch p are: 

Oswitchp* ( Tssc , Tssd ) » 

{ Tea € Oswitchp" ( Tssc , Tssd ) I V Tsb € Oswitch p a ( Tssc , Tssd ):Tsa4 Tsb } 

Where Oswitchp ( Tsc , Tsd ) - 
// Tsc - <) V Tsd - ( ) Then < ) 
If Datum (Tsc 1 ) "PA Consistent-tags ( Tag-set ( Tsc 1 ) , Tag-set (Tsd 1 )) Then 

{Datum (Tsd 1 ) ,Merge-tags ( Tag-set ( Tsc 1 ) , Tag-set (Tsd 1 )))® 

Oswitchp (tTsc,t Tsd ) 
If Datum ( Tsc 1 ) # P A Consistent-tags ( Tag-set (Tsc 1 ), Tag-set (Tsd 1 )) Then 

Oswitchp (tTsc,t Tsd ) 
Otherwise < ) 

Last we define the extended Inbound Switch operator. The Iswitch* operator takes 
N + 2 arguments: the control tagged-stream-set, Tssc, and N + 1 data tagged-stream-sets, 
Ts8 r Iswitch* applies I switch to each AT + 2-tuple from the Cartesian product of Us inputs 
sets. Iswiteh stops when it finds tag-sets which are not consistent, as usual, but note that 
Iswitch recurs differently than the previous operators; although it always takes "t" of Tsc 
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(the control tagged-stream), it only takes "t" of the selected data tagged-stream, Ta r 
The precise definitions of Iawiixhl and I switch are: 

Iawitch* ( Taac , Taa ,..., Taa N ) - 

{Taa €lawitch a (No-taga, Taac, Taa ,...,Taa N ) | 

V Tab € Iawitch? ( No-toga , T»«c , Taa , . . . , Tm^ ) : Tact 4 Tab } 

Where No-toga* {} 

AndIavritck(Tga,Tac,Ta Q ,...,Ta N Y~ 
IfTac-OThenO 
If Datum (Tsc,)-OA r« -<> Then <) 

• •' • • • 
// Datum ( Tac ,)« 2V A Ta N -() TA«n ( > 

Jf Patam ( r*c, ) - A Conaiatent-toga ( 2**7* , Tog-aet ( Tac' ) , Tag-8«t ( Ta ' ).) TAen 
(Datem ( r« l ) ,Merge-taga ( fys ,Tajr-««tf( f M* ) iTug-aeiiTa^)))® 
Iavnteh(Merga-tag8(Tga f Tag-aat{Tac l ),Tag-a9tiTa^^^ 
TTac,TT8 ,...,Ta N ) 

• • • • • • • • • 

If Datum ( Tac { ) - N A Con*t«t«ttt-tesr* ( Tga , Tajr-M* (Tsc 1 ) , Tog-aet ( Ts y ' ) ) TAen 
< Datum ( fs^ 1 ),Merge-taga ( 2V« , raff-8e< ( Jw 1 ) , Tog-aeU T8# l » > © 
I switch ( ilf erge-toga ( Tff* , Tog-aet ( Tsc l ) , Tog-aet ( Ta^ 1 ) ) , 

Tr8c,r8 ,...,Tr» y ) 

Otherwise ( ) 

Continuity of the Determinate Operators 

Theorem 6.1: The extensions of determinate operators, as defined above, are 
continuous functions in all of their tagged-stream-set arguments. 

Let F"bca function on tagged-streams which is continuous and thus isotone, and 
let {I'm,, Taa v ..., Taa] be a chain whose supremum is Taa. (Although F may be a 
function of several arguments, we are considering continuity in one argument at a time 
so for brevity we elide the others and write only FiX).) Consider the sequence of image 
sets: {i' , * , (2 , s»,),F w (rssj),...,^ l (ra«)};-note that this is not the extension of F" as above, 
just the normal application of a function to a set of arguments. If {Ts K , Ta K+l ,...> Ta), 
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where Ts : e Tss r is a chain whose supremum is Ts, then {F u (Ts K ),F a (Ts K+l ), ..., 
F"(Ts)} is a chain whose supremum is F a (Ts). (We start the chain with K instead of 1 
because the cardinality | Tss t | is isotone in I and hence not all possible chains start in 
Tss v ) But, although F u (Ts r ) € F u (Tss t ), it is not necessarily the case that F u (TSj) € 
FHTsS;) because fHTss t ) is the Prefix-reduction of F^iTsSj). However, if F^iTSj) e 
fHTsSj). then F u {Ts J+i ) e FHTss J+l ). because F u (Tsj) € F^iTsSj) means that for all 
F^iTsaj) € fHTsSj): FHTSjULF^Tsaj) and F^Tsa,) 4F u (TSj). But then T Sj < Ts J+l 
and Tsaj<Tsa J+l taken together imply that F u (TSj)<F u (Ts J+l ) and that FHTsajX 
F a (Tsa J+l ). Thus F u (Ts J+l )llF u (Tsa J+l ) and F (Tsa J+i )4F u (T3 J+l ) by Lemma 4.1. 
Therefore, every chain of F^Ts^ (an element of F u (Ts* 7 )) has a closed-above subchain 
F u (Ts y>/ ) (an element of FHTss^j)) which is disjoint from all other such chains and 
thereby establishes the necessary u + 1 sequence of injections from F ( (Tss K ) to 
FHTss K+i ) and on to FHTss). This proves that {fHTss^FHTssJ, ...,F ( (Ts8)} is a 
chain and fHTss) is its supremum. gj 

Theorem 6.2: The extended operator Hold* is continuous. 

The continuity of Hold* follows easily from Theorem 6.1; we merely observe that 
"©" is isotone on streams. Note that our results in Chapter 4 concerning streams carry 
over to tagged-streams, since the pairs {Datum, Tag-set) make perfectly good stream 
elements, that is, the codomain of a stream function may be any set with an equality 
relation. The only care we must take is to show that our resultant tagged-streams obey 
the tag-set extension rule. It is clear that a tagged-stream whose first element has an 
empty tag-set obeys the tag-set extension rule if the remainder of the tagged-stream 
obeys the rule, which it does by assumption, being the input. H 

Theorem 6.3: The extended operator Sop* is continuous in all of its arguments. 

To show that Sop* is continuous on tagged-stream-sets, we first note that Sop* is an 
extension of Sop", which obeys the precondition of Theorem 6.1, because Sop u is the 
continuous completion of Sop (by Lemma 6.7) if Sop is isotone. So we need only prove 
that Sop is isotone on tagged-streams. We prove that Sop is isotone in its 7-th (Data- 
path) argument by showing that if TSj <, Tsxj then Sop F (Ts x , ..., Ts p ..., Ts N ) «§ 
Sop F ( Ts ,,..., Tsx r ...,Ts N ) . The proof proceeds by induction on the finite ordinal 
Dom(Tsx) = N; note that Ti^-Oiff Dom{Tsx x ) - { }, and that Sop F (Ts v ...,(>, ..., 
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Ts N )"( ) for any 1 <IZN. Substituting TsXj in the definition of Sop F ( Ts ,,..., Ts r ..., 
Ta N ), we get: 

Sop^Ta^Tax^Ta^)" 
IfT8x T -()Thm{) 
If 3J*I:T8j-<)Then() 

If Consistent-tags ( Tag-set ( Ts , ' ) , Tag-set ( TsXj ) , rop-ae* ( Ta^ 1 ) ) Then 
{F{Drtum{Ta/),lkAwn{Tax l ).,Datum(Ta lf x )}, 

Merge-tagalTag-aertTa^fTag-attiTaXj^tTag-MtiTa^)))® 
Sop F (r r«,,T Tax r r Ta N ) 
Otherwise < ) 

We assume in the steps that follow that Vl < J £ N: Ts x »* ( ), since otherwise Sop F (Ts v .. ., 
Ts r ...,r«^)-< ). The base step is: T«* / -() implies r« / *< ) so that Sop F (Ta ,,..., Ts,, 
...,T« y > - (> - Sop r (r«,,...,r»* r ...,r«p Thea^^ 

1. If r« 7 - ( >, then Sop r (Ta if ..., Ta r ..., T*^) - ( >, which is the prefix of any tagged- 
stream. If r8 r **<), then Taj 1 -Ta*/ and rTa^rTaXj. Now if Tag-setiTs/) is not 
consistent with some Tag-set(Tsj l ), then Sop^CTs ,,..., T8 r ...,Ts N )-(), which is the 
prefix of any tagged-stream. Now if Tog-setlTs/) is consistent with aH tog-setiTaj 1 ): 

Sop r (Ta l ,...,Ta I ,...,Ta N )- 

{F(Datum(Ta r l ), ... ^DatumiTa/ ), ... ,Datum(T* N ] )), 

Merge-tagsi Tag-set ( Ts, '),..., Ta0-s«* ( 7*/ ),..., Tofir-w* ( Ta N l ))> © 
Sop^(T Ta x ,... ,t r« r , ... ,t Ts^) 

Sop,,(r«, ,... .raa;,, ... ,Ta N )~ 

{F(Datum(Ta I i ),...,Datum(Ta I l ),...,Datum(T8 s 1 )), 
Merge-tag8{Tag~8et(Ta i l ) r ...,Tag-aet(T8/),...yTag-8tt(Ta N 1 )))® 
Sop F (rTs l ,...,TT8x r ...,TTa lf ) 

Sop F (T8 x >...,Tsx r ...,Ta N y>- 

{ F (Datum ( Ts/ ),... ,Datum ( Ts/ ) , . . . ,Datum ( Ts^ 1 ) ) , 
Merge-tags ( Tag-set ( Ts ,'),..., Tag-set ( fa/ ),..., Tag-set (Ts N l )>) © 
Sop^C t Ts, , ... , t fa*,, ... , t Ts n ) 
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Hence, by the isotonicity of "©" we deduce that Sop F (Ta lt ..., Ta r ..., Ts N ) £ Sop F (Ta lt 
...,Tsx r ...,Ts N ) given the inductive hypothesis, that Sop F (rTs lt ...,tTs 7 , .,.,tT8 n )£ 
Sop F (TTs l ,...,TTsx I ,...,rTa N ). This is the inductive hypothesis because rTaXj £ tTs, 
and Dom(rTax^ ■ N. 

Next we must show that the tagged-stream which results is indeed a proper one 
which obeys the tag-set extension rule. To do this we apply Lemma 6.4. Assume J<K, 
and let Ta J and T8* be the J-th and IT-th elements in the tagged-stream output of 
Sop F (Ta ]t ..., Ti p ..., Ta N ). Also assume that all its inputs Ta T obey the tag-set extension 
rule. By unwinding the recursive definition of Sop F we see that Tagseti. Ts J ) - 
Merge-taga(Tag-aet(Ta x J ),...,Tag-aet{Ta N J )) and the same for K. Thus we can easily 
see that Ts obeys the tag-set extension rule — refer to the above equations for 
Tag-aet(Ta J ) and Tag-aet(Ta K ) and note that the inputs Taj obey the tag-set extension 
rule (Tag-aetiTafiZ Tag-aetiTa*) for all/). Therefore since each application of Sop 
obeys the rule we conclude that Sop* obeys the tag-set extension rule as well as being 
isotone. g] 

Theorem 6.4: The extended operator Oawitch^ is continuous in both of its arguments. 

Again we prove this by first proving that Oawitch is isotone on tagged-streams, then 
appealing to Lemma 6.7 and Theorem 6.1. We prove that Oawitch p is isotone in its first 
argument by showing that if Tac £ Tacx then Oawitch p (Tac, Tad) £ Oawitch p {Tacx, Tad). 
The proof again proceeds by induction on the finite ordinal Dom(Tacx)»N; note that 
Tacx — < > iff DomiTacx) - { } and that Oawitch p « ), Tad) - < ) - Oawitch p (Tac, ( )). Substi- 
tuting Tacx in the definition of Oawitch p1 we get: 

Oawitch p ( Tacx ,Tad)<* 

IfTacx~()VTad-{)Then() 

If Datum ( Tacx 1 ) - P A Consistent-toga ( Tag-aet ( Tacx 1 ) , Tag-aet ( Tad 1 ) ) Then 

{Datum(Tad l ),Merge-taga(Tag-8et(Tacx 1 ),Tag-aet(Tad 1 )))® 

Oawitch p ( t Tacx , t Tad ) 
If Datum ( Tacx 1 ) *PAConaiatent-taga ( Tag-aet ( Tacx 1 ) , Tag-aet ( Tad 1 ) ) Then 

Oawitchp ( t Tacx , r Tad ) 
Otherwise ( ) 
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We assume in the steps that follow that Tad ¥> ( >, since for any Tac and Taex, 
Oawitch p {Tae, ())«()- Oawitekp{Tacx, ( ». The base step is: Taex - ( > implies Tac-() 
so that Oavritch F (Tac, Tad) - Oa%oitch p {{ ), Tad) -Oawitck p (Tacx, Tad), The induction 
step is: let Dom(Tacx) - N + 1. If Tac - < ), then OawitehpiTac, Tad) - ( >, which is the 
prefix of any tagged-stream. If Tae * ( ), then r«#* * T*ex l attd *?** £ rTmx. Now if 
Tog-attiTac 1 ) is not consistani with <-2VifH*t(fWfc thi* ®H««ci^{?»e, 3T«d) - ( ), which is 
the prefix of any ugged-stream. But if Tag-8«t{T»c { ) is consistent with rtv-wKrad'), 
and Dotiim(r«c')#P then: 

Oswttcfcp ( Tsc , Tsd ) « Oawitchj, ( t Tsc , t Tsd ) 

OtottcA^ ( Tscaf , Tsd ) «• Oaxoitehp ( t Tsc* , r Tsd ) 

Hence, since Dom(rTaex) - AT and tTsc 3 tTm», we may assume the induction hypothe- 
sis, that OavritchplrTac, rTad) <g OrwitchpirTacx, rtad). If however Tag-aat(Tac l ) is 
consistent with Tag-aet(Tad l ), and DatumiTae 1 ) - /» then:' 

Oavritchp ( Tac , Tad ) « 

(Datem ( Tad 1 ) ,Merga-taga ( Tatf-M* ( Tsc' >, 1%-sst ( iTsd 1 )))© 
OswtteAp ( t Tsc , t T«d> 

OsiottcAp ( Taex , tfsd ) - 

{Datum ( 2W ) , Af«rjw-tap« ( Tag-att ( Tscac' ) , Taflr-wiS C Tid 1 )) Y® 
Oawitchp(rTacx,rTad) 

So OavritckpiTacx, Tad)- 

\Datum{Tad x ),M9rg€-taga(Tag-a*t{Tac l ),Tag-aet{Tad 1 )))® 
Onoitchp(rT8cx,T Tad) 

Hence, by isotonicity of "©" we deduce that Oawitch p {T8c, Tad) £ 0*witehp(Tacx, Tad) 
given the induction hypothesis, that Oav>\teh p (rTac, TTttD^Oawitck/TTsex, rTad). 

Now we must show that Oawiteh obeys the tag-set extension rule. Again we apply 
Lemma 6.4, this, time to the tagged-stream output of Oawitck p . Assume JoutZKout, 
and let Ta Jout and Ta X9Ut be the Jout-th and Kout-th elements of Oswitch p (Tac, Tad). 
Note however that Ta Ko%t does not necessarily derive from Tac* ** and Tad* -01 " because 
the recursion schema skips elements of the input tagged-stream (i.e. whenever 
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I?o*ttm( Tac 1 ) # P) . But Tog-aeti Ta K,mt ) - Marga-togai Tag-aet( Tic* 1 *), Tag-aa0M m *» 
for some iftn £ Xoiif and similarly for /<mf 'aad^i/t*. ^Twmi ®e same argument we used 
to show that the output of Sopp obiys the ta^set extension rule shows that the output of 
Oswitchp does. Therefore we conclude that Osl&^^olbeVi %e tag-set extension rule 
as well as being ketone. B 

Theorem 6.$; The extended op^ra^^ (by 

Lemma 6.7 and Theorem 6.1). 

The proof that 7a«KtcA U isotoae is moce d^icaUt. Fuist we show that Iawitek is 
isotone on tagged-stream** then the isotoiii^ofJ«tttti8** follows directly fijptn Theo- 
rem 6.1. We prove that /*wti<jfc is isot«Mie in a4 jar r* 7 arguments by showing that if for 
all £ I £ N, Ts r £ T$x r then lawitchiTga, Tae y !»«$#■ . ..*T* } ^<±J*%0itch(Tg$ i Tt6+ Tax , . . ., 
Tax N ) for any T^« e Tog-aet. This time the proof proceeds by simultaneous induction on 
the finite ordinals DtmiTax,^ *» N t ; note that ^QtmiTaXj) m {\ iff Ts^ «■ < >, and that 
Iawitch(Tgs, ( >, Ta Qt ..*, Ts^) » p,, but that it is not necessarily true that IawitchiTga, Ta , 
...,(>,..., T* N ) ■ C ). Substituting Ts» / (for all I), into the, definition of I twitch we get: 

Iawitek ( Tgs , Tac , T«* , . . . , Tax K ) - 
7/Tac-(>r*«n(> 
J/ Datum ( Tac l )-0 A r»x -<) Then < > 

• ■ ' » • • • 

If Datum, ( Tac , ) - -V A Tax^ - < > Then < > 

//" flaiitm ( Ttc, ) - A Co*»i8Untrtag*( Tga, Hbg-aet&Tiki 1 ), TograetiTat^)) Then 

Iawitek {.Mtrg*-tog*(Tga, Tag-sat (Tte^^ag-satiTaX^)), 
t Tac,TTax ,...,Tax N ) , 

• • •■ • • • • • • 

J/ Ztatum ( Tsc, ) - AT A Con«wt«n*-ta0s ( Jjrs , 2>0-««t ( ^ac 1 ) , Tayg-aat (Tax N l ) ) TAen 
{ £aiit» ( Tsas ^ ') , Afjff e-*af a ( Tfljs , raf-wt ( Tae^tTag-aeLiTax^ 1 )))® 
Iavntck(M*rg$-tag?(Tga,T^ 

TTac,Tax ,...,TTax N ) 

Otherwise ( > 
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We assume in the steps that follow that Tac # ( >, since for any Ta v IawitchiTgsA >» Ts Q , 
..., Ta N ) - ( >. The base step is: f or all S I Z N, T«% - < > which implies f or all £ J & N, 
Ta T - ( > so ±a.tIawitch{Tga, Tac,Ta , ..., Taj » IawUeh(Tga, Tac, < >,...., ( *) * 
IawitcHTga, Tac, Tax , ..., Tax N ). The induction step is; let ^^^^DomiTaxj) -N+l. 
There are several cases to consider depending on whether DatumiTac 1 ) -/ or not, 
whether Ta T - () or not, and whether the tag-sett are consistent or no*. 

If Dotum(Tac x Y- 1 and Tsj-O.then Iawitch{.Tga,Tac,Ta^,...,Ta s )* <> which is 
the prefix of any tagged-stream. If DtttumiTac 1 ) */ and Ta^ih then Ta/ - Tax/ and 
TTtj <f TT«» r Now if r?#, rew-srtCrJw 1 ) and Tar^T^ 1 * are not mutually consistent, 
then lawitchiTga, Tac, Ta 6 , ,.., Ta^ ~ ( ), which is the preffas of any tagged-stream. But if 
they are mutually consistent, them 

Iawitch ( tga , Tae , Ta Q , .. . , Ta t , .. . , Ta N ) «■ 

( Doftm ( T» t l ) , Marga-tagai Tga , Tog-eat ( Tae 1 ) , T<Hjr-««t ( 7s/ ) j > © 
Iawitch ( Marge-toga ( Tflfs , raflr-a«t( Tie 11 ) , f ajr-wt t W, ' ) ) , 
t Tac,Ta ,...,T Taj,...,Ta N ) 

Iawitch(Tga,Tac,Tax ,...,Tax I ,...,Tax N )" 

(Datum ( Tax T l ) , Merge-tags ( 2>» , Tajr-«#t ( 2W ) , Tagf-wt ( Tax/ ) ) > © 
Iawitch ( Merga-toga ( Tffs , ra0-s«< '( 2W ) , f og-aet ( Tsa?/ ) ) , 
TTac,Ta ,...,TTaxj,...,Ta N ) 

lawitchiTga, Tac, Tax ,...,Tax i ,...,Tax lf )~ % " 

( Datum (Ta/) , Marge-toga ( Tff« , Tag-act {Tac 1 }, Tag-act ( Pa / ' ) ) > © 
Iawitch (Marge-tog* ( 2V» , Toff-siti iW ) , Tap**** ( T*, 1 ) L 
Trae,rs ,...,TTaa: / ,.,.,2'8 y ) 

Hence, by isotonicity of "©" we conclude that IawitehiTga, Tac,Ts Q , ...,Ts r ...,Ts jV )£ 
/8u>ttc/i(Tgrs, Tac, r8* , . . . , Tax t , . . ., Tax N ) given the induction hypothesis, that 
IawitchiTgam, rTac, Ta , ..., rTa r ..., Ta y ) £ I awitch{T gametic, Ts Q , ..., rTax r . . ., Ta N ) 
where Tgam»Merge-taga{...). In any case, we are reducing "S, 0i j iif Dom(TaXj), so the 
induction is well founded. 

Proving that Iswitch is isotone in its first argument (Tac) is a relatively straightfor- 
ward induction (similar to that of Sop) and is therefore omitted. 
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The proof that Iswitch obeys the tag-set extension rule is more complicated than 
any of the previous such proofs. The reason for this is that the recursion schema 
includes an extra variable Tga, which accumulates the tag-sets generated by the previous 
recursion levels. 

Now let Ts=-Iswitch({ },Ts Q , ...,Ts N ) and consider Ts J . Upon unwinding the 
recursion, we see that Tag-setiTSj) => Merge-tags(Merge-tags(..., Tag-set(Tsc J ~ l ), 
Tag-aet(Ta Pa Qa )), Tag-aet(Tsc J ), Tag-set(Ta pb Qb )) (assuming Ts J even exists). Now by 
associativity and commutativity of Merge-tags, we see that Tag-set(Tsj) « 
Merge-tags(Tag-8et(Tsc J ), Tag-set(Tsc J - x ), ..., Tag-8et(Ta pa Qa ), Tag-8et(Ts pb Q % ...) - 
Merge-tags(Merge-tag8(Tag-set(Tsc J ), Tag-8et(Tsc J ~ l ), ...), Tag-aet(Ta Pa Qa ), 
Tag-aet(Ta pb Qb ),...) But by since Tsc obeys the tag-set extension rule, Tag-aet(Tac J ~ i ) £ 
Tag-set(Tsc J ) etc., thus by Lemma 6.5 we get Tag-8et(Ts J )"Merge-tags(Tag-8et(Tsc J ), 
Tag-8et(Ts Pa Qa ),Tag-8et(Ts Pb Qb ),...). Now we apply associativity and commutativity of 
Merge-tags again in order to group together the Tas with the same subscript (i.e. to group 
together the data inputs) to get Merge-tagai.Tag-8et(Tsc J ),Merge-taga(Tag-8et(Ta li x ), ...), 
...,Merge-taga(Tag-aet(Ta N l ), ...)). (Although we show Ta^ for all /, it must be 
understood that the whole M-tags subexpression is present iff 3Af < J: I € Datum(Tsc M )) . 
Now by N applications of Lemma 6.5, we derive that Tag-aetiTaj) - 
Merge-taga(Tag-8et(Tsc J \Tag-set(T8 Co ^ T ' e ' 0J) \ 

Count(T8c,I,J) is the number of times the value / appears in the set {Datum(Tsc M ) I M 
<J}. By the same argument, we also derive that Tag-aet(Ta K ) ■ 
Merge-tag8(Tag-set(T8c K ),Tag-8et(Ts c °™« T > c - - K) ),..^^ 

assuming that Ts K even exists). Since Tsc and all Ts r obey the tag-set extension rule, we 
see that if K > J then Tag-set(Tsc J ) C Tag-seHTsc*) and Tag-aetiTs^^ 7 "- 1 ^) C 
Tag-aet(Ts I CountiT " !j ' K) ) for all I £ N (since Cwnt(T8c,I,J) < Count(Tae,I,K) for all / S 
N). Thus by N + 1 applications of Lemma 6.4, we conclude that Tag-aet(Ta J , 
Tag-set(Ts K )) so that Ta obeys the tag-set extension rule too. Therefore we have proved 
that Iswitch* obeys the tag-set extension rule as well as being isotone. B 

Definition of Non-determinate Primitive Arbiter 

In order to define the Arbiter operator, we first define an auxiliary function 
Extend-taga which takes two arguments Choice and Tga, and a parameter A. Extend-taga 
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appends the number Choice on to the tail end of the Choice-sequence in the Tag* Tg (in 
Tgs), whose Arbiter-name is -4. Its precise definition is: 

Extend- tags A ( Choice , Tg* ) - 

{TgeiTge I Arbiter-name{Tg) + A}V 

{ < A , Choice-sequence {Tg) © Choice) f Tg t-Tfis A Arbiter-name ( 7>) - A } 

WhereSOX-Ss 
AndDom(Sx)-Dom(8) + l 
AndS^^lf I €Dom{S)Th*nS I OthmrwieeX 

The Arbiter A operator takes N+ 1 arguments which are tagged-stream-sets, ?M r and 
one parameter A which is the Arbiter-name (we omit further references to A in the 
explanation). The Arbiter A applies Arbmerge A to each N+ 1 -tuple from the Cartesian 
product of the r»«'s and Prefix-reduces the result. Arbmerge A takes N + 1 tagged- 
streams and merges them *U possible ways, producing a Prefix-reduced set of tagged- 
streams as its result, it does this by using Arbmerge AJ for each / £N and taking the 
union of their results. Each Arbmerge AJ uses Arbmerge . recursively to merge the tail of 
the /th tagged-stream with all the rest, and attaches the head of the Xth tagged-stream to 
each tagged-stream in the resulting set. The N sets which result at each recursion level 
are united to form a single set which is the overall result of that level. Arbmerge A and 
Arbmerge AJ both take an additional argument, Tgs (initially the set with one Tag whose 
Arbiter-name is A and whose Choice-sequence it empty), which records the arbitrary 
choices made so far in the recursion. The precise definitions of Arbiter A , Arbmerge A 
and Arbmerge A j are; 

Arbiter A ( Tss , . . . , Tss^ ) - 

{ Tea € U Arbmerge/ ( Tg* A , Tss , . . . , Tse^)\ 
VT8beUArbmerge A "iTgs A ,Ts9 ,...,T*»#yiTsa4Tsb} 

Where Tgs.- {(A,())} 

. y ■ 

And Arbmerge A ( Tgs , Ts , . . . , Ts N ) - 

{ Tea € \J IiN Arbmerge AJ ( Tgs , r» ,..., Ts s ) | 
V Tsb e \J IiIf Arbmerge AJ ( Tgs , Ts , .. . , T*#): Tsa 4 Tab } 
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And Arbmerge AJ ( Tga , Ta Q , . . . , Ts N ) ■» 
If Taj-OThen {<>} 
If Conaistent-tags ( Extend-taga A (I, Tga ) , Togr-ae* ( Ta/ ) ) TAen 

Ta € Arbmerge A (Tgax,Ta ,...,T T« / ,.*.,r« i? )A 
Tgax — Merg$'taga ( Extend-toga A ( /* Tga ) , Tag-teti Ta/ ))} 
Otherwise {()} 

The fact that Arfcmerg^*' is continuous on its tagged-stream arguments, even though its 
result is a tagged-stream-set, will be made clear by Lemma 6.10. Note that the uses of 
Arbmerge A m in the definition of Arbiter A make use of our function-of -argument-sets 
convention only with respect to the Taaf. although Tga A is a set, Arbnerge A a wants a 
such a set as its first argument. 



Continuity of the Non-detenninate itHiifer 

To prove that Arbiter A is isotone, we first prove • that Arbmerge A is isotone in its 
tagged-stream arguments. Note that the output domain is the domain of Togged-itream- 
aeti whfle the input domain is that of Tagged~tirtama. Siace they are^both poaets however, 
isotonicity is well defined. First, however, we ptwe -another handy lemma about 
tag-sets. 

Lemma 6.8: For any legitimate tag-set Tga, TgaSExtend-taga A (C, Tga). 

From the definition of Extend-taga we see that an element Tgx of Extend-taga A (C f 
Tga) is either already an element of Tga (if ArbxUr-name(Tgx) # A) or it derives from 
the element Tga in Tga such that Arbiter-name(fga) - Arbiter-nameiTgx) and 
Cho%ce-aeqvsneeiTg)±Ckoice-aequenee(Tgx) (if Arbiter-name(tgx) - A) . H 

Lemma 6.9: If VJ £ N: Taj jg Tax t then Arhme¥ge A (Tga$T!* , . .., Tt^) i Arbmerge A (,Tga, 
Tax v ..„Tax H ). 

To show that this is true, we need an injection from Arbmerpe A (Tga, 7> , ..„ T9#) to 
Arbmerge A (Tga,Tax Q ,...,Tax lf ) such that each element of the first is a prefix ■("■•£") of 
an element of the second. Since Ts t £ Tax, for all ISN, we see that Tax/ - Ta, 1 
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(assuming the non-trivial case DomiTa^ { }). Upon substituting Tax r for Ta t in the 
definitions of Arbmarge A and Arbmerg$ AJ we get: 

Arbmerge A ( Tga , Tax Q , . . . , Tax H ) * 

{ Tsa € U r s ^ Arbn*rge A a (Tg* , r«a: , . . . , Tax N ) | 

And Arbmerge AJ (Tga,Tax Q ,...,Tsx N )'* 
IfTax J "{)Tfun {<>} 
If Conaiatant-toga ( Ext$nd-toga A ( I , Tga ) , Tog-att ( I**/ ) ) Tften 

r»z € v4r6wMty« vl ( r^aa , Tax Q , . . . , t r«* x , . . . , Tax N ) A 
Tgax-Marg€~taga(Ext0nd>Uwa A (I,Tga),Tag?80i(Ta I l )) } 
OtAtrurtM { < > } 

Now consider a stream Taa in i4T*merp« A (r0«,r« o ,...,J> Ar ), and consider its first 
element Tsa 1 . Clearly, Taa € Arbmerg9 AJ (Tga,Ta ,...,Ta N ) for some I Taa 1 ~ 
WaiumiTa^Tgax), and ?T#i€ Avbmarga A (Tg9x>Ta Q ,...rrTMj*,~,Ta^ where Tgax" 
Marg9-taQa(Ezte*%Uag9 A lL r TM$, Tag-iatiTaj 1 }), From this a we conclude Jha* fee may 
be characterized by its decision sequence or "oracle" J^ i»4^fc r jr ; * £>es«»<Ts»). The 
same oracle may be applied to the elaboration of : 

Arbmerge A (Tga f Tax Q ,...,Tax lf )- 

{Taa,€\J ISN Arb7»9rga A j(Tga t Tax 9 ,...,Tax N ,) | 
V T«6 € U /sy Artmerge AJ ( T^« , r«* , . . . , Tsa^ ) : Taa 4 Tab} 

This will give rise to a set of one or more streams since the recursion can proceed at 
least as far as before (because Ta^Taxj for all /). If we pick an arbitrary stream Taox 
from this set, we easily see that Tso j§ Taox since the oracle J x that generates Taa 
generates a prefix of Taox, and the elements of that prefix are equal to the correspond- 
ing elements of Taa since those elements derive from the T* t prefixes of the Tax r 
Furthermore, if Tab* Taa is in Arbm*rge A (Tga,Ta ,...,Ta N ) the Tabic in ArbnurgejTga, 
Tax , ..., Tax N ) of which it is a prefix must not equal Taox by Lemma 4.1. Thus we have 
established an injection from Arbmatg* A {Tga, T « , ...; Ta N ) to Arbmarge/Tga, Tax ,..., 
Tax N ) such that each element of the domain is a prefix of its image. Therefore, 
Arbmerge A (Tga, Ta , . . ., Taj «J Arbmarge/Tga, Tax , ,. ., Tax^ 
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Each stream in Arbmerge A (Tgs, Ts Q , ..., Ts N ) obeys the tag-set extension rule. This 
follows easily from Lemmas 6.6 and 6.8. 

The result of all this is that Arbmerge A is indeed isotone in its tagged-stream 
arguments and each element of its output prefix-reduced tagged-stream-set is a proper 
tagged-stream. H 

Lemma 6.10: The completion Arbmerge A " of Arbmerge A is continuous in its tagged- 
stream arguments Ts v 

The fact that the output of Arbmerge A is a tagged-stream-set does not upset the 
continuity result of Lemma 6.7. All that is required is that the codomain is <o directed 
set complete, which it is since it is to chain complete. 

Now we can state and prove the key result of this chapter: the theorem that 
completes the basis for a denotational semantics of non-determinate data flow programs. 
It is principally for this theorem that the chain complete poset of Tagged-stream-sets was 
developed in the last chapter. 

Theorem 6.6: The non-determinate Arbiter operator is continuous in each of its 
(tagged-stream-set) arguments. 

The proof of this is similar to the proof of Theorem 6.1. First, to shorten the text of 
the proof, we abbreviate Arbmerge A (Ts , ..., Ts p , ..., Ts N ) as A mp(Ts p ) and 
Arbiter A (T 88 Q , ...,Tss p , ...,Ts8 N ) as Ap(Tss p ), where the P-th argument is the one of 
interest. (During the rest of the proof, Ts x and TsSj will refer to an element of the 
respective chain, not to the 7-th argument of Arbmerge A or Arbiter A , unless otherwise 
stated or implied by appearance as an explicit argument.) Now, by Lemma 6.10 we 
know that Amp" is continuous and thus isotone. Let {Tss x , Tss v ...,Tss} be a chain 
whose supremum is Tsa, and consider the sequence of image sets {Amp"{Tsa^, 
Amp a (T88 2 ),...,Amp°(Ts8)}. Note that this is not the extension of Amp", just the 
application of a function to a set of arguments. Now if {Ts K , Ts K+i , ..., Ts] (where Ts f 
e TsSj) is a chain whose supremum is Ts, then {Amp"(Ts K ), Amp"(Ta K j), ..,, 
Amp"(Ts)} is a chain whose supremum is Amp u (Ts), by Lemma 6.10. We wish to 
establish an u + 1 sequence of injections from Ap(Tss K ) to Ap(Tss K+l ) and on to 
ApiTss) which demonstrates that they form a chain. Here we must depart from the 



-70- 



proof of Theorem 6.1 since the result of AmpiTa) is a tagged-stream-set rather than a 
tagged-stream. Noting that Arbiter A ({Ta „} , ..., {Taj) - Arbmtrge^Tga, r« , .... Ta N h 
and that ApiTaaa) s Atnp»(T$$a) t suggests that we form the union of the maps which 
show that Amp^Ta^Amp^a^ uniting over all fs^ € Ti% r W* do this and then 
restrict the domain of this relation to the set Ap(Taa K ) to get a Sanction Fj, since we 
thereby discard any first elements of the relation pair which were e ^- Tjut this 
function is injective foUows easily from Lemma 4.1. Suppose r g (Tag,)^F M {Tab) where 
Taa y Tab c ApiTs* K ). Then either Taa± Tib or Tab* Tan by Lemma 4.1. But ApiTaa K ) is 
prefix-reduced, so this is impossible. Hence F K Is ah Injection from Ap(Taa x ) to 
Ap(Taa K+l ) such that each element is a prefix of its Mag*, which establishes that 
Ap(Tu K ) * Ap{Taa K + ,). By repeating this construction sufficiently often (« + 1 times! ) 
we establish that {Tu v Tn v ..., T$*} is indeed a ehefeb ©iiJlgfpdltfreaawets whose 
supremum is T»», since each element of T*$ is the supremum of a chain of tagged- 
streams. Therefore we haws proved that Afr i* tea«ais»e^t*tfr' i* waa arbitrary, so 
Arbiter A is continuous in each argument. (S 

First Order Fix-Points of Non-detenniitstelM^Iift^gTttttts - 

Having established that all me DFPL primitive operators are continuous in their 
tagged-stream-set arguments, we conclude that any recursion-free DFPL program can be 
solved for its first order fixed-point behavior, as indicated in Chapter 4. The details of 
the data domain do not matter, as long as it is w-cfcain complete. Similarly, the details 
of the operators do not matter, as long as they are continuous functions on the domains. 
We will therefore undertake a simple fixed-point computation. 

Figure 6.1 shows a non-determinate DFPL program with a loop, for which we will 
compute a first order fixed-point. Note that this time we inirodhce input from outside 
the loop. We do this to get a non-trivial answer since none of the opefitOW in the loop 
generate any data. The Every-other operator is as defined in Chapter 4 and will again 
ensure finiteness of the result. The Arbiter operator is as defined earlier in this chapter 
except that we drop the parameter A which distinguishes among Arbiter's since we only 
have one of them. 
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To solve this loop, we cut it at the point labeled X, then we solve the equation X - 
Arbiter({{A , 8)},Every-other(X)). To make the solution process more illuminating, we 
introduce the auxiliary variable Y, and generate approximate solutions to the above 
equation in two steps: Yj - Every-other(X ,) and X I+X - Arbiter{{{A , B)}, Y { ). Naturally 
we start the approximation with X - i » {( >}. The first approximation is: 

X, - Arbiter^ { (A , B >},{()})» { (Ao,Boo > } 

7, - Every-other(X l ) - { Uo > } 

The second approximation is: 

Z 2 »i4r6iter({(4 , B) } , Y, )- { (Ao,Boo,Aooi ), <i4o,i4oi,Soio>} 

Y 2 **Every-other(X 2 ) m { (i4o,4ooi),(i4o,Boio)} 

Note that the fact that the second input to Arbiter is already tagged (by this selfsame 
Arbiter) constrains the way that Arbmerge can do its merging — the tag generated by 
Extend- tags must be consistent with the input tag. The third approximation is: 

X i - Arbiter ( {{A , B ) } , Y 2 ) » { Uo ,floo ,Aoai ,i4oon > , {Ao ,Aoi ,Boio ,Boioi > } 

Y i "Every-other(X 3 ) m {(Ao,Aooi) ,{Ao,Boia)} 

Note that the tags as well as the data is dropped by Every-other from the output tagged- 
streams — the output therefore indicates only those arbitrary decisions that actually 
entered into the particular output. Note also that the generation of X 3 involves 
Prefix-reduction. Part of the computation of X 3 involves evaluating ArbmergeiLA, B), 
Uo,ilooi». This generates the empty tagged-stream and the tagged-stream Uo.doi, 
floio), both of which are discarded by the Prefix-reduction which occurs when Arbiter 
generates its result tagged-stream-set. 

Since Y 3 =■ Y 2 the fixed-point computation has converged and the solution is X - 
{Uo,Boo,4ooi,i4oon),(i4o,i4oi,Boio,floioi)}. If we were cut the graph at Y instead of X, 
the first approximation would start with Y Q =» {< >}, so that X x - Every-otheHY Q ) - {( >}. 
This would delay the convergence by 1 step, but the fixed-point would obviously be the 
same. 
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-7- 
Conclusion 



Overview 

This chapter ties up loose ends and suggests directions for future work in the 
semantics of Data Flow Languages. Some of the loose ends considered are: "fairness" 
of non-determinate DFPL programs, functional behavior of DFPL programs with loops 
and recursion, and the meaning of "bottom" (or i> in DFPL's semantics. Directions for 
future work are suggested in the areas of: our semantics as a means to proving equiva- 
lence of DFPL programs, operators as valid DFPL data and the relation to reflexive 
domains. 

Explanation of the Anomaly of Brock and Ackerman 

In [B4A-77], Brock and Ackerman present two small non-determinate data flow 
programs which exhibit anomalous behavior. The anomaly is that their operational 
behavior is different from the behavior predicted by a simple denotational semantics 
based on sets of streams. From this, they correctly conclude that a Semantics based only 
on sets of streams (which they call histories) is inadequate to characterize non- 
determinate systems. In our model, based on set of tagged streams, their two programs 
correspond to different functions, and thus their different behavior is not anomalous. In 
particular, the first stream element output by the second program is tagged, while the 
first stream element output by the first program is not tagged. The details of this may 
easily be filled in by examining their note, and will not be elaborated here. 

"Fairness" and the Arbiter 

As mentioned in Chapter 1, a non-determmateserviee program may or may not 
treat its users "fairly". The usual definition of a "fair" program is that the program 
never keeps the user who requests service waiting for more than a specified or reasona- 
ble period of time. This can be refined by specifying what period of time is permissible. 
Two possibilities are: no user need wait an infinite amount of time for a request to be 
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serviced; no user need wait more than a bounded amount of time for a request to be 
serviced after it is presented to the system. 

Neither of these definitions of "fairness" arjs directly applicable to DFPl. since its 
semantics has no notion of time in the usual sense. The semantics of DFPL does, 
however, have the notion of relative order of appearance of data items. (This ordering 
is induced by the ordering of the positive iftteltfers which is the domain of the function 
which defines a Tofywi-strsam.) Thus the aboW definitions of "fairness" can be recast 
as follows: any user's request will be serviced after a finite number of other' users' 
requests are serviced; any user's request will 'be serviced after a bounded number of 
other users' requests are serviced. Let us now investigate whether either of these 
definitions of "fairness" can be satisfied within the semantics of DFPL. 

Since the source of all non-detenaMWt»l»hai«er in* DFPL ia the Arbiter, the ques- 
tion boils down to th» "fairness" of tkoArUtev.* That is* if several sources of requests 
are to be merged into one for consideration by same processing program, even if the 
program has internal queues fornnsatis«e4s»eq«estsvth« Arbiter makes the initial 
decision as to which request gets served or even queued lor service. 

Recall that neither in the determinate semantics of streams (cf. Chapter 4) nor in 
the non-detenninate semantics of tagjed-sfream-sets (cf. Chstpter 6) do we have the 
notion of a datum in one stream preceding or following a datum in another stream. 
Therefore, we cannot even express the concept of a datum not being delayed at an 
Arbiter while more than a bounded number of other mpttts are processed. There is 
another related concept which is expressfbie however. That is the idea any stream which 
is the output of an Arbiter will never have more than a bounded number of contiguous 
data items which are passed through from any single input stream. This couM easily be 
realized by changing the definition of the Arbmerge A suhfunction (cf. Chapter 6) to 
have extra arguments which counted how many data items from each input have been 
accepted so far and constraining thereby which Arbmerge^ 1 subfunction was to be called 
at each recursion. Unfortunately, this approach has a crippling flaw. Suppose the 
bound on the number of contiguous acceptances is ti and suppose that one input to the 
Arbiter is presented with a stream of length N + M and &e other inputs with empty 
streams. Then the output can only consist of the first N data items of the non-empty 
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input stream, the remaining M items wiH never be, accepted. Thus m the name of 
bounded delay "fairness", we impose infinite delay in certain circumstances! Therefore 
we can reject bounded delay "fairness" as incompatiMe with our fairly simple semantics 
of DFPL. 

The notion of finite delay "fairness" still requires consideration. An Arbiter may be 
said to have finite delay if any input datum eventually shows up in the output stream no 
matter what sequence of arbitrary (but allowable) decisions were made by the Arbiter. 
More precisely, we would say that for any input stream T*, and for any J in its domain, 
then for any output stream Ta in the output tagged-stream-set Tat there exists a finite K 
such that Ta* ■ Ta/. Now imagine a two input Arbiter such that its left input is 
presented with the singleton stream ift) (for simplicity, we ignore the fact that the inputs 
are really sets), and its right input is presented with, the stream IB , B , ... , B). The 
output of this Arbiter, according to its definition in Chapter 6, must be the tagged- 
stream-set {{A , 5, ..., B}, -{fcyi , ... , Si, .*.*<£♦ ... v Jf* 4*}i (Here we drop the tags 
in the interest of brevity, they are deducibie fn»i the ciata which are distmct,) The last 
stream in this tagged-stream-set has the A : ^.^m^M:^I^^A^o^m»t^:hmf long a 
finite stream of fl's we feed it, the Arbiter will always produce such a stream as an 
element of its output tagged-stream-set. Since the Arbiter "is continuousy its output when 
confronted with an infinite input stream is die supremum of its outputs generated from 
the finite input streams which have that infinite stream as their supremum. 

To compute this supremum, let us adopt a bit of notation which departs somewhat 
from our previous notation. Let (A N ) stand for a stream qf N Occurrences of A, rather 
than the N-tk element of a stream -.A,. ( We can. distinguish this usage by the precise 
typography of the letters A, B etc.) Then our examale may be written as: 

Arbiteri(A),{B N ))- 

{<B K ,A,B*-') \ 0SK1N}- 

{ (B N , A > }U{ (B* , A , B N -*) | S K<N\ 

Now these tagged-stream-sets clearly comprise a chain for increasing N (they must 
because Arbiter is isotone), and that chain has a supremum. By our construction of 
such a supremum (cf. Chapter 5), each tagged-stream in each tagged-stream-set must be 
in a chain of tagged-streams which has a tagged-stream supremum. The question now is, 
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does the infinite stream < 5") appear in the supremal output set? The answer is no, --^ 
because there is no chain of sequences in the chain of sets which has that infinite stream, 
as its supremum. A set does exist which is an upper bound of the chain of sets and 
which contains that stream, but it would not be the least upper bound. SI 

Therefore, although the continuity of the ArbiUr precludes its being fair in the 
bounded delay sense, it is fair in the sense of having ihky finite" delay. 



Second Order Theory 

The set of continuous functions from a chain complete poset to a chain complete 

poset themselves form a chain complete "piyii'^(tbr'' v 'ai^'''p^nlH*lse order fMar-77, 

m Ros-77]. Thatis.FKGIff vi:^ibi(^^ : Tmtt, e%ulion^ ih such ftmctiona also 

have fixed-points which can, fr prihaple, De computed by the same ntetndfll We call the 

theory of fixed-points in the function domain the second order theory to distinguish it 

*«;</-, from the first order theory of fixed-points in the domain of streams. There "are two basic 

classes of DFPL programs whose fuoc4c«al f^a>poinu are of interest: the iterative and 

the recursive. J^ how programs 

% which have both iterative and recursive parts may be dealt with. 

Figure 7.1 shows a prototypical DFPL deflaed,«pertttor with an iterative body. We 
wish to determine what F is given G. That is, we have the equation Y-G(Y,X) but we 
desire an F such that Y «■ F(X). This schema is sufficiently general to encompass all 
iterative procedures. The variables Z and T may in general be tuples of tagged-stream- 
sets where Y includes all feedback and output paths and G includes the entire body of 
the procedure. If not all feedback paths are desired as outputs, an appropriate projec- 
tion function can be applied to Y to yieM thf ,Qu$pjyM. but this changes the solution in a 
trivial way only. 

Let us assume that G is continuous «hd that^dfcl** 0^27 where D is our chain 
complete domain. Let & x • X Y . (Hjt t f)-' Tneia $ x ■&' continuous in its single argument. 
To solve r- G(Jr, f) for a given X is equlVaBi to yftifij? 1 ? W x (?9; which : "is done by 
finding U{ i,G x (i.),G x (G x (j.))l. TcTsolve foTtfte / a^#^owe^et, we must allow X to 
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be an actual argument. Therefore consider the sequence: 



F -A-X.i 



F,-XJf.G(2T,x) 

F 2 -\X.G(X,G(X,x)) 

F } -\X.GU,GU,G(X,i))) 



Clearly each F t is a continuous function, because G is continuous in each argument, and 
both partial application and composition preserve continuity. Also, the set {Fj\ I> 0} 
is a chain in the function domain, that is, F Q % /, $ J a jB »» This follows by induction 
from the facts that G is isotone in its second argument and VJT: x S GiX, x). Therefore, 
the chain has a continuous supremum F - Lll**, 1 1 i 0} which is the continuous function 
we wanted. 

We conclude fflmi this atgumew *** a loop for a 

body has a well defined semantic function which describes its behavior. 

Second Order Fixed Point* ef Recursive Programs 

Figure 7.2 shows a prototypical DFPL defined operator with an recursive body. 
Again, by suitable bundling of data paths and repackaging of operators, any recursively 
defined operator can be made to look like-P. The equation to be solved is thusT- 
F{X)-H(Gl(X),FiGr(X))), where Gl is the part of G that generates the left output and 
Gr is the part that generates the right output. Since this equation must hold for all X* we 
abstract to get F - X X . H(GHX}, FiGHX))). Abstracting once again, we convert this to 
the second order (or functional) equation F-\E.\X,H(GHX),E(Gr(X)mF). Thus 
we wish to find the (second order) fixed-point of the functional \E. XX. H (GJ(X), 
E(Gr(X))\, But we know that any such functional, consisting of compositions of (first 
order) continuous functions and function, variables,, is (second order) continuous. 
Therefore, it has a least fixed-point, and that fixed-point is the recursively defined 
function F. 
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We deduce from this argument that any DFPL procedure which has a recursive body 
corresponds to a well defined semantic function which describes its behavior. Further- 
more, DFPL procedures which involve both loops and recursion can be solved in a similar 
manner to yield their overall semantic function. The proper way of determining the 
semantic function of a large program, consisting of many procedure definitions and uses, 
is of course to solve for the semantic function of as small units as possible, then to build 
up the function for the whole program out of these units. 

"Bottom", Strictness and Termination 

In most treatments of denotational semantics [Man-74, S&S-71, Sto-76] the bottom 
element of the data domain represents the totally undefined datum, while the bottom 
element of a function domain represents the totally undefined function. The bottom 
datum, i, is then (reasonably enough) taken to represent the "result" of a non- 
terminating computation. That is, the partial function which the program computes is 
extended to a total function by defining it to yield x where it was otherwise undefined. 
Given this interpretation of 1, it is also reasonable to demand that most functions be 
"strict", that is, that they yield i as their result if any of their arguments are i. This 
follows from the operationally reasonable notion that it is impossible to invoke a subrout- 
ine until the computations of all of its arguments are finished. Strictness is not demand- 
ed of all functions however, the If -then-else function is usually only strict in its predi- 
cate so that it can be used to terminate recursions and iterations. 

In the semantics of DFPL, the bottom element of the function domain indeed 
represents the totally undefined element, but the interpretation of i in the data domain 
must be different. The data domain of DFPL, recall, is based on the notion of Streams, 
therefore its bottom element is the (set consisting of) the empty stream. The empty 
stream, however, is definitely not the "result" of a non-terminating computation, but 
rather is the definite result of a computation which has not yet received enough input to 
generate output on that port. (Note that much output may have appeared on another 
port, a luxury not permitted in most programming languages.) Furthermore, DFPL 
functions need not be strict at all. In fact, of the primitives, only the Oswitch and the 
Pc/'s are strict; the Iswitch, Arbiter and especially the Hold (which has only one input) 
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are not strict. Therefore, i in the data domains of DFPL is not an •♦undefined" element 
which is added out of mathematical necessity (ie. to totalize partial functions and to 
dean up the partial order) but is a rather natural object which Is as much a part of tftt 
notion of streams as zero is of the integers. 

Program Correctness and Equivalence 

As we stated in the introduction to this thesis, it is necessary to have a precise 
semantics for a programraing language in order to b? able to prove things •*>°« t P ro * 
grams. Given a denotational semantics for a programming Language, as we have for 
DFPL, it may be possible to determine the overall function computed by a program in 
that language. Having done so, itmay then be fwstibk to«h*w j^t rtas fuae^m meets 
a specification (program correctness), or that it is tine ssatte overall function as that 
computed by another program (progi^equivalen^^^^^ gives a basis for 

doing such proofs, but it does not make them mtiversf^ t^^ 

semantics can do that. However, our semantics incorporates a model of non-determinate 
behavior, which many other sen^nticsl»vetroubted>id^w*th. 

Referring back to Figures 2.10 and 2.1 1, we can now see that these two miniature 
programs are indeed equivalent in their overall functionauty up to homomorphism 
(assuming that F is determinate and history independent, /.*. X* • F(tfO). That is, the 
X, Y and Z outputs of program 2.10 are (smgletoait sets of tagged streams; whereas the 
outputs of program 2.1 1 are just streams, so we must map eitci singleton set to its 
element and remove all tags. This result follows directly, from the denotational defini- 
tions of the various operators, we will not give the details as they consist merely of 
substitution into the defining equations, and then applying the homomorphism. Note 
that the Arbiter in Figure 2.10 is an augmented operator: its horizontal output is a (set 
of) stream(s) of index numbers, appearing in synchronization : with the regular (vertical) 
output, such that each number merely says which input port is currently selected. 

Operator Valued Data and Reflexive Domains 

As mentioned in chapter 3, our current denotational semantics for Dt»PL does not 
include operators (functions) as data, and thus has no need for reflexive domains. To 
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meaningfufly add operators to DFPL as data v*lues|we would 'need aa Apply operator 
which would take such data as input. Unfortunately, -if is not clear how to define an 
Apply operator in an informal operation sense, much less in a precise denotational sense. 
It is reasonable to assume that the Aj»p^ op«ater wottld accept a directed grnph or 
equivaloat reprcxenution of the funotioo h was «o apply, and that it would "connect" 
that function to the> ether inputs and output of t |he4#pfc*jan4 then "start up" the new 
subnetwork.' The problem with this mod$l is; when dees -.-*$» appUowtion terminate? 
There is, of course, no problem with an operator which does not terminate, the peculiar- 
ity of Appty is that it se^^ inherently to 1 ^ one function datum 
from it ostensible stream of function data. This iiifue to^h&fio* that it Is in general 
undecklaWe whether a subnetwork has terminated or not. One might get around this 
difficulty by defining a more ^^v^^-^pf^^ptammfi--^-^-'- 

One possibility is the following: the Apply operator receives as input a representa- 
tion of a running subnetwork rather than just Jta^ function. That is, it receives the 
network representing the operator together with any streams in progress. It also has an 
input, betides the input$in4 outputs w^ must 

be **putted" in order to make the applied snlsMieHf^k'^H^u^ one transition (we are 
taking in operational terms again). The Appi y operator continues running the subnet- 
work being applied is tettf a* this input far pujned withiTrwe. When a Matf*'. is supplied 
instead, the current "state" of the subnetwork is dttmped?out on an auxiliary output port 
of the Appiy. This output value amy be fed in to the ,«4ppiy later to resume execution, 
fly this means wef ineate the umiecidaWity of wnnmation of the applied subnetwork, 
we leave it to the usefcof^he ^ppiy to deteirojne when to stop. Thit makes meaningful 
the notion of a stream of things to be applied? it is similar to a stream of jobs to a batch 
operating system. 

Although, from the operational point of view, the applicable object is a function 
network plus its mternilldi^l^W^^othlf ^c^n of Trains to streams from the 
denotational point of view, since such functions already' exhibit the behavior of having 
an internal state. The extension to nbn-detennJnate ^ functions should fit into titil 
framework as it did before the Applf operator. This ^suggsatt thit we might want a 
reflexive domain [Sto-17 J as our underlying domain, that is, a domain which not only 
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contains ordinary data bat also the continuous f unctions from that domain to itself . This 
domain D would have to satisfy ;th» em#^&&&^$*$*Gt&* i ^^ r0 ftQ®U*-* 
£]), where Q is the domain of simple data (nua^bers, strings, records etc), and "a" 
denotes isomorphism, "©" denotes disjoint union, and [D~D] denotes the continuous 
function* from DxoD. TbJt » neither the usual roftexivc domain equation, due to the 
presence of the set constructor, nor is it quite the foww- ittift^i equation, due to the 
fact that the sets of tagged streams are not plain sett: 

This needs further research, both to investigate the utility and cleanliness of this 
solution and to formulate it precisely in the denotatioaal model. (Note that the Apply 
operator is not necessary in order to have the .vm^^^'^W 1 '^^* it more is like the 
"program loader" of conventional operating systems.) 

Relation to the Lattice Formulation of IMta Types 

Dana Scott has developed a rather complete theory of computation based on 
complete lattices and continuous functions [Sco-76]. HU underlying approach is to 
model everything in terms of one universal domain, the domain ^f« of all subsets of the 
non-negative integers, which it *n algebraic and m$ts#wm kfatemeM ^U as being a 
topological space. In tins domain, continuous functions on the domain may be repre- 
sented by encodings of their graphs>4sets of argument- value pairs), as can data values 
themselves. Reminiscent of Godel numbering, encodings a#e «»tt erf ,m»ge»s, that is, 
elements of #«. A single number is encoded as the singleton set containing that 
number. The finite subsets B N of #» may be enumerated (as E N ■» { K^ . . *K M _ ,'} 
where N - 2 ^„2 i ") and the result of applying a (continuous) function f# an arbitrary 
element of the domain is defined by F(X) - lfj(£y). I S^X). Since functions map 
elements of 9w to elements of Jf w, functions may have arguments and values which are 
sets, e.g. 6U 10 +1 ■> 7 U 1 1. In fact, Scott is able to express the both the lambda calculus 
and a good amount of recursive function theory in this domain, including proofs of 
validity of lambda conversion rules, the continuity of lambda definable functions, the 
first and second recursion theorems, and the recursive non-enurnerahulty,of equations in 
the lambda calculus. 
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The fact that functions take sets as arguments and deliver results which are sets 
suggests that the domain &u might be useful for expressing non-determinacy. However, 
the main purpose to which Scott puts this capability is the definition of data types as 
virtually arbitrary subsets of &<*. He does this by introducing a class of functions called 
retracts which are idempotent functions on &o) that map the data type to identically to 
itself, and other elements onto the data type. Then, by defining operators which allow 
combination of retracts, he is able to show that certain recursively defined data types are 
the minimal fixed-point solutions to equations involving retracts. For example, the data 
type of trees, both finite and infinite, is the solution to the equation Tree a Nil + (Tree x 
Tree) where "+" and "x" are operators on retracts analogous to union and cartesian 
product. 

The generality of the domain &u, in particular its ability to express sets of data, 
would make it a possibility as an underlying model of the semantics of non-determinate 
DFPL. Certainly the tagged-streams needed could be encoded as sets of integers as easily 
as functions can be. However, whether this would clarify the semantics is doubtful: 
encodings of this sort are rarely noted for their transparency. Nor is the explicit 
machinery for dealing with non-determinacy already developed in this model. The 
existence, completeness and continuity of the relevant domains and functions has already 
been established for non-determinate DFPL. The treatment of operators as data is 
probably better examined in the framework of power domains as noted below. 

Relation to Power Domains 

The powerdomain construction of Plotkin [Plo-76], as clarified by Smyth [Smy-78], 
bears some similarity to our poset of tagged-stream-sets, there are some important 
differences however. The most important is that Smyth assumes different domains, a 
domain S of states, and a domain R of resumptions (similar to continuations). The 
states are the states of the abstract machine, while the resumptions are mappings from 
states into sets of states (disjointly united with state, resumption pairs). The reflexive 
domain equation is thus R a [S - &(S © S x R)), where the powerset constructor, 9, is 
needed in order to express possible non-determinacy. The problem then is, how does 
one solve such equations? 
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To do this, Smyth introduces quasi-ordered predomains which are sets of outcomes 
of (non-determinate) computations. These are ordered by the "Milner ordering", which 
is only a quasi-order: 

SET" 

VXcS: 3r«r:7SIA 
VreT: ZXeSlYSX 
The elements of this domain may be viewed as cross sections of a tree which represents 
the non-determinate computation; each path from the root to a leaf corresponds to a 
particular sequence of arbitrary choices made by an instance of the computation. Smyth 
observes that this model and this (quasi) ordering forces one to make "unwelcome 
itontificatioiw" of ottteosnw ^ a true 

potet. He suggests that this could be remediedby taking arcs of the trees rather than 
just their cross eeelieas. This is essentially equivalent to our use of tagged-stream-sets, 
except that we have streams of data rather than recessive outcomes obtained by letting 
the computation run ever longer. Furthermore, although Smyth suggests category theory 
as a basis for the improved analysis, we make do with th? more conventional mathemat- 
ics of sets and sequences. 

Since our underlying domain, tagged-stream-seta, is a t*ue poset and has a simple 
structure, it seems likely that our recursive domain equate* slated above ran be solved 
in a straightforward manner using the techniques of Smyth and Plotkin. This is an 
especially promising area for future research. 
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